mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 09:55:06 +03:00
Miranda Limonczenko
0d465e7b5f
Closes FE-3966 ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## Problem - The admonition uses both 'tip' and 'note', but the visual distinction has long-ago collapsed. - 'Note' is used far more frequently than 'tip' - The two are very similar and it is confusing to know which one to use when they are visually identical ## Solution Collapse 'tip' and 'note' into one by removing all places where there is 'tip' and updating all references to 'tip' into 'note'. **Note:** This PR also resolves new broken links flagged by the E2E docs checker. It may move to another PR since E2Es keep erroring. ### Specific changes See below for an AI-generated list of changes: - **Type system** — removed `'tip'` from `AdmonitionType`, its `TYPE_TO_VARIANT`/`TYPE_LABEL` entries, and the test case in [`packages/ui-patterns/src/Admonition/](packages/ui-patterns/src/Admonition/) - **Remark plugin** — [remarkAdmonition.ts](apps/docs/lib/mdx/plugins/remarkAdmonition.ts) now maps mkdocs `tip` → `note` - **Lint allowlist** — `tip` dropped from `supa-mdx-lint.config.toml` - **Content migration** — all 109 files with `type="tip"` (across `apps/docs`, `apps/www`, `apps/studio`) converted to `type="note"`; zero remaining hits confirmed by repo-wide grep - **Style guide** — `CONTRIBUTING.md` and `contributing/content.mdx` updated to describe 4 admonition types instead of 5 ### Usage before implementation See the usage table that points toward 'note' as being dominant across all apps: Here's the usage table: | Location | `note` | `tip` | |---|---|---| | apps/docs | ~480 | ~143 | | apps/studio | 34 | 6 | | apps/www (blog) | 19 | 3 | | packages/ui-patterns (tests) | 3 | 1 (parametrized) | | design-system / ui-library / packages/ui / packages/common | 0–1 (test fixture only) | 0 | ## Preview links | App | Page | Search text (Ctrl+F) | Verify | |---|---|---|---| | docs | [/docs/guides/ai-tools/byo-mcp](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/ai-tools/byo-mcp) | official MCP TypeScript SDK | callout's aria-label="Note" | | docs | [/docs/guides/ai-tools/mcp](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/ai-tools/mcp) | MCP server is available at | callout's aria-label="Note" | | docs | [/docs/guides/ai/python-clients](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/ai/python-clients) | Click Connect at the top of any project page | callout's aria-label="Note" | | docs | [/docs/guides/auth/audit-logs](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/auth/audit-logs) | Disabling Postgres storage reduces your database storage costs | callout's aria-label="Note" | | docs | [/docs/guides/database/tables](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/database/tables) | access a custom schema through the Supabase Data API | callout's aria-label="Note" | | docs | [/docs/guides/troubleshooting/edge-function-404-error-response](https://docs-git-admonition-collapse-note-tip-supabase.vercel.app/docs/guides/troubleshooting/edge-function-404-error-response) | Always configure an appropriate time frame | callout's aria-label="Note" (was single-quoted type='tip') | | www | [blog: cli-v2-config-as-code](https://zone-www-dot-com-git-admonition-collapse-note-tip-supabase.vercel.app/blog/cli-v2-config-as-code) | Detecting config drift | callout's aria-label="Note" | | www | [blog: cli-v2-config-as-code](https://zone-www-dot-com-git-admonition-collapse-note-tip-supabase.vercel.app/blog/cli-v2-config-as-code) | Setting Edge Function secrets | callout's aria-label="Note" | | www | [blog: nosql-mongodb-compatibility-with-ferretdb-and-flydotio](https://zone-www-dot-com-git-admonition-collapse-note-tip-supabase.vercel.app/blog/nosql-mongodb-compatibility-with-ferretdb-and-flydotio) | If your network supports IPv6 connections | callout's aria-label="Note" | Note: the `www` rows use the `zone-www-dot-com` preview host, not the `docs` one you gave — since blog pages are served from the www app, not docs. ## Manual testing 1. Open preview links for affected pages. 2. Inspect. Open console. 3. Paste the following in and see there is no 'Tip' on the page: ``` document.querySelectorAll('[role="alert"]').forEach(el => console.log(el.getAttribute('aria-label'), el.textContent.slice(0,60))) ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Standardized informational callouts across docs and tutorials from **“Tip”** to **“Note”**, updating multiple examples and guidance blocks. * Updated a few related doc references/links and conditional “Next steps” content. * **UI Updates** * Switched various in-app banners and notices to the **“Note”** style variant. * **Bug Fixes / Improvements** * Removed support for the retired **“Tip”** callout type and aligned docs linting, component behavior, and aria labeling to the remaining admonition types. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
75 lines
3.8 KiB
Plaintext
75 lines
3.8 KiB
Plaintext
---
|
|
title: Deployment & Branching
|
|
---
|
|
|
|
Deploying your app makes it live and accessible to users. Most apps have at least two environments: a production environment for users and one or more staging or preview environments for development.
|
|
|
|
Supabase provides flexible options for deployment workflows of various complexity.
|
|
|
|
## Recommended workflow
|
|
|
|
You can deploy your Supabase project with GitHub:
|
|
|
|
1. Develop locally using the [Supabase CLI](/docs/guides/local-development)
|
|
2. Push changes to your GitHub repository
|
|
3. Deploy automatically to your Supabase project from your `main` branch
|
|
|
|
This workflow works on all plans and does not require branching.
|
|
|
|
If you have branching enabled (on the Pro Plan), you can extend this workflow with preview environments for pull requests.
|
|
|
|
## Environment management
|
|
|
|
You can maintain separate development, staging, and production environments:
|
|
|
|
- **Development**: Develop locally using the [Supabase CLI](/docs/guides/local-development)
|
|
- **Staging / Preview (optional)**: Use [branching](/docs/guides/deployment/branching) to create preview environments for pull requests or long-lived staging environments (Pro Plan)
|
|
- **Production**: Deploy changes from your GitHub repository or your own CI/CD pipeline
|
|
|
|
## Deployment
|
|
|
|
You can automate deployments using:
|
|
|
|
- The [Supabase GitHub integration](/dashboard/project/_/settings/integrations) (recommended)
|
|
- Deploy changes from your `main` branch
|
|
- Works on all plans
|
|
- With branching enabled (Pro Plan), can also create preview environments for pull requests
|
|
- The [Supabase CLI](/docs/guides/local-development) in your own continuous deployment pipeline
|
|
- The [Supabase Terraform provider](/docs/guides/deployment/terraform)
|
|
|
|
## Frequently asked questions
|
|
|
|
### Is GitHub required?
|
|
|
|
No. GitHub integration is recommended, but you can deploy using the [Supabase CLI](/docs/guides/local-development) in your own CI/CD pipeline without connecting a GitHub repository.
|
|
|
|
### Do you need a paid plan?
|
|
|
|
No. The GitHub integration and CLI-based deployments work on all plans. Branching (preview environments for pull requests) requires the Pro Plan.
|
|
|
|
### What gets deployed?
|
|
|
|
Database migrations in your `supabase/` directory, plus Edge Functions and storage buckets that are declared in `supabase/config.toml`. Other local configuration files (such as API or Auth settings) are ignored by default. See the [local development guide](/docs/guides/local-development) for details on the directory structure.
|
|
|
|
### Can you use your own CI/CD pipeline?
|
|
|
|
Yes. You can use the [Supabase CLI](/docs/guides/local-development) or the [Terraform provider](/docs/guides/deployment/terraform) in any CI/CD system (GitHub Actions, GitLab CI, CircleCI, etc.).
|
|
|
|
### How does collaboration with other developers work?
|
|
|
|
Use Git branches to work on changes independently and share them with your team. When a change is ready, merge it into `main` to deploy it to production. If you're on the Pro Plan, you can enable [branching](/docs/guides/deployment/branching) to automatically create a preview environment for each pull request, so you can review and test database changes before they go live.
|
|
|
|
### What is branching?
|
|
|
|
Branching creates isolated preview environments for each pull request, so you can test database changes before merging. It is an optional feature available on the Pro Plan. See the [branching guide](/docs/guides/deployment/branching) for details.
|
|
|
|
### What advantage does branching offer?
|
|
|
|
Branching gives each pull request its own isolated Supabase environment with a full copy of your database schema (without any production data), so you can validate migrations and test your app end-to-end before merging to `main`.
|
|
|
|
<Admonition type="note" title="Self-hosting">
|
|
|
|
Read the [self-hosting guides](/docs/guides/self-hosting) for instructions on hosting your own Supabase stack.
|
|
|
|
</Admonition>
|