Deploying your app on Vercel
Deploy a Next.js or other frontend on Vercel against a SupaHost project. Environment variables per environment, redirect URLs for preview deployments, function regions and what to skip.
Vercel works well with SupaHost. Your app talks to the project over HTTPS with supabase-js, so serverless and edge functions don't hold database connections and there are no pool limits to think about.
The one thing that differs from Supabase Cloud: the Supabase integration in the Vercel Marketplace connects Vercel to Supabase's own platform, so it doesn't apply here. You add the environment variables yourself, which takes a minute.
Add the environment variables
In Vercel, open your project, go to Settings → Environment Variables and add the values from your SupaHost project's Connect tab (subtab App):
| Name | Value | Environments |
|---|---|---|
NEXT_PUBLIC_SUPABASE_URL |
https://app-one.acme.supahost.space |
Production, Preview, Development |
NEXT_PUBLIC_SUPABASE_ANON_KEY |
the anon key |
Production, Preview, Development |
SUPABASE_SERVICE_ROLE_KEY |
the service_role key, only if server code needs it |
Production (and Preview if needed), marked Sensitive |
NEXT_PUBLIC_SITE_URL |
https://recipes.example.com |
Production |
Use the prefix your framework expects for browser-visible values: NEXT_PUBLIC_ for Next.js, VITE_ for Vite apps, PUBLIC_ for SvelteKit, NUXT_PUBLIC_ for Nuxt. Never give the service_role key a public prefix.
Or from the terminal with the Vercel CLI:
vercel env add NEXT_PUBLIC_SUPABASE_URL production
vercel env add NEXT_PUBLIC_SUPABASE_ANON_KEY production
Redeploy after changing variables; NEXT_PUBLIC_ values are inlined at build time.
Separate data for previews
Preview deployments run your newest code. If they point at your production project, an unfinished feature can write real data. Better options:
- A staging project. Create a second project on the same instance (for example
app-one-staging) and give the Preview environment its URL and keys. - A branch (Pro and above). Branch the production project from its Branches tab, with or without data, and use the branch's URL and keys for a preview you're testing. Delete it when the pull request merges.
Each project and branch counts toward your plan's project allowance.
Allow the redirect URLs
Sign-up confirmations, magic links, password resets and OAuth all send users back to a URL that Auth must trust. On the SupaHost project's Auth tab:
- Set Site URL to your production domain, such as
https://recipes.example.com. - Under Redirect URLs, add one entry per line:
https://recipes.example.com/**
https://*-acme-team.vercel.app/**
http://localhost:3000/**
- Click Save Auth settings. Changes apply within about a minute.
Vercel preview URLs include your team or account slug, so a wildcard on that part (https://*-acme-team.vercel.app/**) matches your previews without trusting every vercel.app site. Replace acme-team with your own slug from a preview URL.
In code, build redirect URLs from the deployment's own address so previews return to themselves:
const origin =
process.env.NEXT_PUBLIC_SITE_URL ??
(process.env.NEXT_PUBLIC_VERCEL_URL ? `https://${process.env.NEXT_PUBLIC_VERCEL_URL}` : 'http://localhost:3000')
await supabase.auth.signInWithOAuth({
provider: 'github',
options: { redirectTo: `${origin}/auth/callback` },
})
Leave NEXT_PUBLIC_SITE_URL unset for Preview so the Vercel URL is used there.
Put functions near your instance
Each request from a Vercel function to SupaHost crosses the network, and a page that runs several queries pays that cost several times. Run Vercel functions in the region closest to your SupaHost instance. For example, for an instance in Frankfurt, put this in vercel.json:
{
"regions": ["fra1"]
}
Close matches: London lhr1, Frankfurt fra1, Singapore sin1, Sydney syd1, Tokyo hnd1. For the US and Belgium regions, pick the nearest Vercel region from Vercel's region list. Your instance's region is on the dashboard's Instance page.
Things you don't need
- Connection pooling settings. supabase-js uses HTTPS. There's no Postgres connection to pool, and SupaHost doesn't expose one to Vercel anyway.
- Vercel Cron for database chores. Jobs that only touch the database can run in the database with pg_cron, visible on the project's Cron tab.
- A Supabase custom domain for Auth to work. It's optional. If you add one later (for example
api.recipes.example.com) through the project's Domains tab, updateNEXT_PUBLIC_SUPABASE_URLand your OAuth providers' callback URLs.