Deploy the application without pretending to host Supabase
Keep the boundary accurate: Adios builds and runs your app, while Supabase continues to provide the external project, database, authentication, storage, or functions you selected there.
App integrations · plans from $10/month
Deploy apps with Supabase.Keep the release clear.
Deploy the frontend, API, or worker that connects to Supabase. Adios runs the application release; your Supabase project remains the external database and backend service.
Keep the repositoryInspect build and logsCustom domains and TLS
Adios deploy
Candidate release
Supabase apps
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source received
02Build completed
03Runtime started
04Health check passed
Promoted route
production.adios.run
A production path for
SupabaseNext.jsReactFastAPIPostgreSQLSecrets
The production path
A working Supabase apps project still needs a safe release.
The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.
Separate public client config from private credentials
Expose only values intended for browser use. Keep service-role keys and other privileged credentials in server-side Adios secrets and out of client bundles.
Verify the real integration before promotion
Use a preview to test authentication callbacks, database access, storage URLs, network failures, and the production domain before the release serves users.
From source to release
Three steps keep the deployment path reviewable.
Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.
- 01
Start with source or a template
Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.
$adios login - 02
Review the deployment contract
Keep commands, runtime or service version, health behavior, and secret references in adios.yaml.
$git diff -- adios.yaml - 03
Deploy and inspect the result
Follow build and runtime evidence, verify the candidate, and open the promoted route or service connection.
$adios up
adios.yaml
Your projectname: supabase-web-app
build_cmd: npm ci && npm run build
start_cmd: npm start
runtime:
name: node@24
port: 3000
health_path: /api/health
env:
NEXT_PUBLIC_SUPABASE_URL: https://project.supabase.co
secrets:
SUPABASE_SERVICE_ROLE_KEY: secret://SUPABASE_SERVICE_ROLE_KEYNever expose a Supabase service-role key through a NEXT_PUBLIC_ variable or other browser-readable configuration.
Deployable starting points
Start Supabase apps from a template when the repository is not ready.
Start from the Node.js 24 Supabase template, then connect it to your existing project with secret-backed URL and key configuration.
Web apps
Supabase-connected Node.js 24
A Node.js 24 starter connected to an existing Supabase project with secret-backed configuration.
JavaScriptnpm
- Template key
- supabase
- Runtime
- node@24
- Repository
- templates
- Source path
- nodejs/supabase
git clone https://github.com/adiosdotdev/templates.git
cd templates/nodejs/supabase
adios upBefore production
Verify the workload.Then promote it.
The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.
Ready when…
- The application uses the correct Supabase project URL.
- Browser-safe and server-only keys are clearly separated.
- Authentication callback URLs include the production domain.
- The app handles Supabase timeouts and permission errors.
Preview when…
- Authentication redirect or cookie domains are changing.
- Row Level Security policies are new or modified.
- The application begins using a privileged service-role key.
Questions, answered
What to know before deploying Supabase apps.
Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.
Does Adios deploy the Supabase platform itself?
No. This landing page is for deploying an application that connects to an existing Supabase project. Adios hosts the application release; Supabase remains the external service.
Can I deploy a Next.js app that uses Supabase?
Yes. Keep public Supabase client settings separate from server-only credentials, configure authentication callback domains, and test server and browser flows in a preview.
Where should the Supabase service-role key go?
Store it as an Adios secret and read it only from trusted server-side code. Never expose it through NEXT_PUBLIC_ variables, static files, logs, or browser bundles.
Can a Python API connect to Supabase?
Yes. Inject the project URL and required server credential into the Python runtime, then test authorization, network failures, and database behavior before promotion.
Can I start from a template?
Yes. The Supabase-connected Node.js 24 starter includes secret-backed project configuration, a process health route, and an example query you can adapt to your schema and Row Level Security policies.
Related deployment paths
Connect the rest of the stack.
Deploy Next.js
Deploy static pages, server-rendered routes, and APIs from one persistent Node.js release.
Deploy React
Build a React application from its existing repository, serve the generated output or production Node.js process, and connect the release to a stable HTTPS route.
Deploy FastAPI
Deploy a FastAPI service with its ASGI import target, dependency install, runtime port, health endpoint, secrets, and promoted release tied to source.
Deploy PostgreSQL
Choose a PostgreSQL version, keep database credentials out of Git, attach persistent storage, connect the application, and verify data after a restart.
The first release
Deploy Supabase apps with the source and evidence attached.
Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.