Bring your app from Vercel and Supabase
The Vercel plus Supabase stack is the default for a reason: it works. What it also does is split one app across two accounts, two dashboards and two usage models, and charge you a base fee on each one whether the app had visitors this month or not. Vercel Pro is $20 a month, Supabase Pro $25, and every further Supabase project adds $10 for its own instance.
Here, one prepaid balance covers hosting, Postgres, transactional mail and a custom domain for every project you run: $10 a month for 1,000 credits, no per-project fee. You do not have to move the database to move the app — most people shouldn't, on the first pass.
Still choosing your destination? The integrated alternatives to Vercel and Supabase compare Appwrite, Firebase, Nhost and ohmyho.st before you start migrating.
What actually breaks when you move
None of this is hard, but all of it is easy to forget. Your agent works through the list; the list is the point.
- Environment variables exist twice. The browser build needs
VITE_/NEXT_PUBLIC_values baked in at build time; the server needs private values at request time. On Vercel both live in one settings pane, so the distinction blurs. Here the build runs with runtime secrets deliberately absent, which surfaces any private value you were reading at import time. - Callback URLs point at the old host. Supabase Auth keeps a Site URL and a Redirect URLs list. Until the new Dev and Prod hosts are in it, sign-in returns to a page that no longer serves your app.
- The database connection changes shape. If you keep Supabase, nothing moves — the app keeps its existing client and publishable key. If you import a dump, the app talks to managed Postgres through the
OHMYHOST_DATABASEbinding instead of a connection string, and apgPool that built fine will fail its health check. - Preview deployments are not environments. Vercel gives every branch a URL; here you get two named deployment environments, Dev and Prod, with environment-scoped secrets. Database data is shared or isolated according to the mode you choose. Dev is protected by default and answers 404 to anonymous requests until someone opens its share link; you can choose public Dev instead when you create the project.
How to move your app from Vercel and Supabase
- Inventory the app. Identify the framework, application directory, package manager, auth provider, database, files, functions and external services. Source alone does not carry database rows, uploaded files or runtime secrets.
- Decide what moves. Keep your authentication provider unless you ask to change it. Keeping Supabase as an external database is the smallest first step: the login and the data stay exactly where they are, and only the front end moves. The Supabase migration Skill inventories each capability you actually use; an installed package is not a reason to replace anything.
- Deploy and verify. Continue the project's current source or select managed current-file versions or GitHub, then follow the deployment Skill. Push the chosen commit when GitHub is selected. Set the target environment's secrets through local stdin or the supported remote private portal input, add the new hosts to Supabase's Redirect URLs, run the migrations, then test sign-in, a protected route, one real write and any mail the app sends. Promote to Prod after Dev passes; an isolated promotion applies migrations without copying Dev rows into Prod.
What it costs after the move
If Supabase keeps the database and the login, this side meters the front end only: the build, the requests, the CPU time, one deployed script and the hostname.
| Item | Credits |
|---|---|
| 10 build minutes | 12.05 |
| 100,000 requests | 9.86 |
| 1M CPU-ms | 6.57 |
| 1 deployed script | 6.57 |
| 1 custom hostname | 32.86 |
| Total: A Lovable frontend that keeps Supabase, with its own domain, for one month | about 67.91 |
About $0.68 of credit value at the standard rate.
If the database moves here too, the month includes its active database hours, with disk and seven-day backups included:
| Item | Credits |
|---|---|
| 20 build minutes | 24.10 |
| 100,000 requests | 9.86 |
| 1M CPU-ms | 6.57 |
| 8 active database hours at 512 MiB RAM, including disk and seven-day backups | 160.00 |
| 2,000 mail recipients | 360.00 |
| 1 deployed script | 6.57 |
| Total: A small app for one month | about 567.10 |
About $5.67 of credit value at the standard rate.
A quiet project keeps only its separately metered resources: a script at about 6.57 credits a month and any customer files. Database RAM stops charging after five idle minutes, while its allocated disk and seven-day backups stay included. Read the workload assumptions before comparing the shared balance with separate base subscriptions.
Sources
- List prices checked on 2026-09-28 — Vercel pricing.
- List prices checked on 2026-09-28 — Supabase pricing.
When to stay where you are
Stay on Vercel if you rely on its preview-deployment workflow for a team, on its image optimization pipeline, or on framework features this runtime does not support. Keep Supabase if you use Realtime, its Storage API or its Edge Functions and do not want to convert them — you can still host the front end here and leave the backend untouched. Moving is worth it when you have several projects, when the base fees outweigh the usage, or when you want one agent to operate hosting, database, mail and domains through one interface.
Compare against Vercel · Compare against Supabase · Cost breakdown · Framework guides · Application auth