mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
## 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 -->
246 lines
5.8 KiB
Plaintext
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"
|
|
/>
|