mirror of
https://github.com/supabase/supabase.git
synced 2026-10-08 19:05:06 +03:00
Alaister YoungandAlaister Young
a8b2f23091
Deployment update checks now receive a timestamp from GitHub’s documented commit API instead of silently falling back to `unknown` when its website response changes. Valid deployment metadata is cached for ten minutes; development and failed lookups are uncached so they can recover. **Changed:** - Validate and normalize the committer date in the shared Next/TanStack handler, preserving the existing response shape and `unknown` fallback. - Exclude only the exact deployment-metadata endpoint from TanStack’s private API cache default; authenticated APIs and server functions retain it. - Keep the client update query unpinned and its existing toast threshold unchanged. **Added:** - Shared-handler tests through both Next and the TanStack adapter for dates, malformed payloads, upstream failures, and recovery. - Tests using the installed Vercel route compiler for root and `/dashboard` cache rules, security headers, and empty Next configuration. ## To test - On the TanStack preview, request `/dashboard/api/get-deployment-commit`; compare its SHA and UTC timestamp with the deployed commit’s GitHub committer date. - Repeat the request to check CDN caching. Vercel consumes `s-maxage`, so use cache-hit/age evidence as well as client-visible headers. - Confirm another API route and a server-function path retain `private, no-store`. - Open an existing project, reload it while clean, and inspect the untouched support form for metadata-related errors. Validation: 60 focused tests, Studio typecheck, scoped ESLint, formatting, knip, and both framework production builds passed. Live unauthenticated GitHub lookup with the configured API version returned the expected committer date. Full source lint ratchet also passed, excluding only generated build directories. Local TanStack browser checks passed for clean project/reload, general settings, untouched support form, and naturally emitted development metadata formatting; no errors or unexpected update toast appeared. The positive two-deployment toast and submitted support-version formatting were not exercised. Deployed native Next previews returned the exact commit SHA and expected UTC timestamp; repeated metadata requests produced CDN HIT responses (ages 26 and 100 seconds). Build logs establish that the staging preview also ran Next, so it does not validate TanStack edge header behavior. A separate preview-only redeployment with a deployment-scoped TanStack override was confirmed to run Vite. It returned the same correct SHA/timestamp, a repeat CDN cache HIT, and private, no-store on the neighboring UTC API. No project settings or production aliases were changed. Installed Vercel compiler tests cover the remaining root/base-path and server-function rules. No new environment variable, token, or dependency is required. Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Supabase Studio
A dashboard for managing your self-hosted Supabase project, and used on our hosted platform. Built with:
What's included
Studio is designed to work with existing deployments - either the local hosted, docker setup, or our CLI. It is not intended for managing the deployment and administration of projects - that's out of scope.
As such, the features exposed on Studio for existing deployments are limited to those which manage your database:
- Table & SQL editors
- Saved queries are unavailable
- Database management
- Policies, roles, extensions, replication
- API documentation
Managing Project Settings
Project settings are managed outside of the Dashboard. If you use docker compose, you should manage the settings in your docker-compose file. If you're deploying Supabase to your own cloud, you should store your secrets and env vars in a vault or secrets manager.
How to contribute?
- Branch from
masterand name your branches with the following structure{type}/{branch_name}- Type:
chore | fix | feature - The branch name is arbitrary — just make sure it summarizes the work.
- Type:
- When you send a PR to
master, it will automatically tag members of the frontend team for review. - Review the main contributing guide to help test your feature before sending a PR.
- The Dashboard is under active development. You should run
git pullfrequently to make sure you're up to date.
Developer Quickstart
Note
Supabase internal use: To develop on Studio locally with the backend services, see the instructions in the internal
infrastructurerepo.
# You'll need to be on Node v22
# in /studio
## For external contributors
pnpm install # install dependencies
pnpm run dev # start dev server
## For internal contributors
## First clone the private supabase/platform repo and follow instructions for setting up mise
mise studio # Run from supabase/platform alongside `mise infra`
## For all
pnpm run test # run tests
pnpm run test -- --watch # run tests in watch mode
Running within a self-hosted environment
Follow the self-hosting guide to get started.
cd ..
cd docker
docker compose -f docker-compose.yml -f ./dev/docker-compose.dev.yml up
Once you've got that set up, update .env in the studio folder with the corresponding values.
POSTGRES_PASSWORD=
SUPABASE_ANON_KEY=
SUPABASE_SERVICE_KEY=
Then run the following commands to install dependencies and start the dashboard.
npm install
npm run dev
If you would like to configure different defaults for "Default Organization" and "Default Project", you will need to update the .env in the studio folder with the corresponding values.
DEFAULT_ORGANIZATION_NAME=
DEFAULT_PROJECT_NAME=