Files
supabase/apps/docs/content/guides/functions/deploy.mdx
T
Danny White 24be387cdb docs: use sign in terminology across guides and style guides (#49877)
## What kind of change does this PR introduce?

Docs update. Aligns documentation and style guides with the **Sign in /
Sign out / Sign up** platform standard.

Closes DOCS-1328. Related to
[#49874](https://github.com/supabase/supabase/pull/49874).

## What is the current behavior?

Docs style guides prefer _login_ / _log in_. Guide prose uses mixed
login and sign in wording.

## What is the new behavior?

- [WORD_LIST.md](apps/docs/WORD_LIST.md) and
[copywriting.mdx](apps/design-system/content/docs/copywriting.mdx)
document the sign in standard
- Design-system auth examples updated
- Guide prose and API reference spec descriptions updated

### Terminology

**Standard:** Use _sign in_, _sign out_, and _sign up_ as verbs. Use
_sign-in_, _sign-out_, and _sign-up_ as nouns and adjectives. Match
Studio UI labels (**Sign in**, **Sign out**, **Sign up**).

**Preserved intentionally:**

| Category | Keep as-is | Example |
| -------- | ---------- | ------- |
| Feature name | social login | `/social-login`, `features.mdx` heading,
OAuth provider section |
| URL slugs | `login` in paths | `/phone-login`, `/login-flows`,
`choosing-login-flow` |
| CLI | `supabase login` / `supabase logout` | Reference ids
`supabase-login` / `supabase-logout`; executable commands unchanged |
| SDK methods | `logout()` | Kotlin/Swift method names in API reference
titles and examples |
| Third-party UI | Provider product labels | Facebook Login, Kakao
Login, portal **Login** buttons |
| Postgres | Database terminology | login privileges, login credentials,
login via role |
| Audit/logging | Log prose | "Generates the following **log** in the
Postgres Logs" |
| Code and routes | Paths and filenames | `app/login/`, `Login.tsx`,
`demos/android-login` |
| External URLs | Third-party login pages | `dash.cloudflare.com/login`,
`console.neon.tech/login`, `vercel.com/login` |
| API identifiers | Event and field names | Audit actions
`login`/`logout`, `should_logout_user` |

## To test

- Run `pnpm lint:mdx` in `apps/docs`
- Spot-check `features.mdx`, `social-login.mdx`, and a provider guide
(e.g. Facebook, Kakao)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Standardized authentication terminology across guides, reference
material, CLI documentation, and copywriting guidance using “sign in,”
“sign out,” and “sign up.”
* Updated authentication instructions, headings, link text, examples,
and SSO guidance for clearer, more consistent wording.
* Corrected related grammar, spelling, hyphenation, and documentation
links while preserving established product names and implementation
commands.
* **Style**
  * Refined code examples with consistent import ordering and spacing.
* **Examples**
* Updated authentication button and menu labels to “Sign in” and “Sign
out.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-09-04 09:10:25 +10:00

246 lines
5.8 KiB
Plaintext

---
id: 'functions-deploy'
title: 'Deploy to Production'
description: 'Deploy your Edge Functions to your remote Supabase Project.'
subtitle: 'Deploy your Edge Functions to your remote Supabase Project.'
tocVideo: '5OWH9c4u68M'
---
Once you have developed your Edge Functions locally, you can deploy them to your Supabase project.
<Admonition type="note">
Before getting started, make sure you have the Supabase CLI installed. Check out the CLI installation guide for installation methods and troubleshooting.
</Admonition>
---
## Step 1: Authenticate
Sign in to the Supabase CLI if you haven't already:
```bash
supabase login
```
---
## Step 2: Connect your project
Get the project ID associated with your function:
```bash
supabase projects list
```
<Admonition type="note" title="Need a new project?">
If you haven't yet created a Supabase project, you can do so by visiting [database.new](https://database.new).
</Admonition>
[Link](/docs/reference/cli/usage#supabase-link) your local project to your remote Supabase project using the ID you retrieved:
```bash
supabase link --project-ref your-project-id
```
Now you should have your local development environment connected to your production project.
---
## Step 3: Deploy Functions
You can deploy all edge functions within the `functions` folder with a single command:
```bash
supabase functions deploy
```
Or deploy individual Edge Functions by specifying the function name:
```bash
supabase functions deploy hello-world
```
## Step 4: Verify successful deployment
🎉 Your function is now live!
When the deployment is successful, your function is automatically distributed to edge locations worldwide. Your edge functions is now running globally at `https://[YOUR_PROJECT_ID].supabase.co/functions/v1/hello-world.`
---
## Step 5: Test your live function
You can now invoke your Edge Function using one of the project's `PUBLISHABLE_KEYS`, which can be found in the [API settings](/dashboard/project/_/settings/api) of the Supabase Dashboard. You can invoke it from within your app:
<$CodeTabs>
```bash name=cURL
curl --request POST 'https://<project_id>.supabase.co/functions/v1/hello-world' \
--header 'apikey: PUBLISHABLE_KEY' \
--header 'Content-Type: application/json' \
--data '{ "name":"Functions" }'
```
```js name=JavaScript
import { createClient } from '@supabase/supabase-js'
// Create a single supabase client for interacting with your database
const supabase = createClient('https://xyzcompany.supabase.co', 'sb_publishable_...')
const { data, error } = await supabase.functions.invoke('hello-world', {
body: { name: 'Functions' },
})
```
</$CodeTabs>
<Admonition type="note">
Note that the `SUPABASE_PUBLISHABLE_KEYS` is different in development and production. To get a publishable key, you can find it in your Supabase dashboard under Settings > API.
</Admonition>
You should now see the expected response:
```json
{ "message": "Hello Production!" }
```
<Admonition type="note">
You can also test the function through the Dashboard. To see how that works, check out the [Dashboard Quickstart guide](/docs/guides/functions/quickstart-dashboard).
</Admonition>
---
## CI/CD deployment
You can use popular CI / CD tools like GitHub Actions, Bitbucket, and GitLab CI to automate Edge Function deployments.
### GitHub Actions
You can use the official [`setup-cli` GitHub Action](https://github.com/marketplace/actions/supabase-cli-action) to run Supabase CLI commands in your GitHub Actions.
The following GitHub Action deploys all Edge Functions any time code is merged into the `main` branch:
```yaml
name: Deploy Function
on:
push:
branches:
- main
workflow_dispatch:
jobs:
deploy:
runs-on: ubuntu-latest
env:
SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
PROJECT_ID: your-project-id
steps:
- uses: actions/checkout@v4
- uses: supabase/setup-cli@v1
with:
version: latest
- run: supabase functions deploy --project-ref $PROJECT_ID
```
---
### GitLab CI
Here is the sample pipeline configuration to deploy via GitLab CI.
```yaml
image: node:20
# List of stages for jobs, and their order of execution
stages:
- setup
- deploy
# This job runs in the setup stage, which runs first.
setup-npm:
stage: setup
script:
- npm i supabase
cache:
paths:
- node_modules/
artifacts:
paths:
- node_modules/
# This job runs in the deploy stage, which only starts when the job in the build stage completes successfully.
deploy-function:
stage: deploy
script:
- npx supabase init
- npx supabase functions deploy --debug
services:
- docker:dind
variables:
DOCKER_HOST: tcp://docker:2375
```
---
### Bitbucket Pipelines
Here is the sample pipeline configuration to deploy via Bitbucket.
```yaml
image: node:20
pipelines:
default:
- step:
name: Setup
caches:
- node
script:
- npm i supabase
- parallel:
- step:
name: Functions Deploy
script:
- npx supabase init
- npx supabase functions deploy --debug
services:
- docker
```
---
### Function configuration
Individual function configuration like [JWT verification](/docs/guides/local-development/cli/config#functions.function_name.verify_jwt) and [import map location](/docs/guides/local-development/cli/config#functions.function_name.import_map) can be set via the `config.toml` file.
```toml
[functions.hello-world]
verify_jwt = false
```
This ensures your function configurations are consistent across all environments and deployments.
---
### Example
This example shows a GitHub Actions workflow that deploys all Edge Functions when code is merged into the `main` branch.
<$CodeSample
meta="deploy.yaml"
path="/edge-functions/.github/workflows/deploy.yaml"
/>