# 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.

Source: https://supahost.app/docs/integrations/vercel · Updated 2026-11-11

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:

```bash
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:

1. Set **Site URL** to your production domain, such as `https://recipes.example.com`.
2. Under **Redirect URLs**, add one entry per line:

```text
https://recipes.example.com/**
https://*-acme-team.vercel.app/**
http://localhost:3000/**
```

3. 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:

```ts
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`:

```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](/docs/cron-queues/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, update `NEXT_PUBLIC_SUPABASE_URL` and your OAuth providers' callback URLs.

## Related

- [Use SupaHost with Next.js](/docs/getting-started/nextjs)
- [Can I use SupaHost with a Next.js app on Vercel?](/kb/nextjs-vercel)
- [Site URL and redirect URLs](/docs/auth/redirect-urls)
- [Redirected to the wrong URL after sign-in](/kb/redirect-to-wrong-url)