Host a Supabase app: deploy the frontend and keep the backend

An app built with React, Vite or an AI tool may use Supabase for authentication, Postgres, Storage or functions. Changing where the frontend is served does not move those services: you can deploy the repository with Projects and keep Supabase as the backend, provided you update its variables and allowed URLs.

This walkthrough covers the frontend of an existing Supabase project. It is not a database migration and does not replace Supabase policies, users, files or functions. Before ordering, check Projects plans and limits and the costs of any external services you keep.

1. Identify the project URL and keys

In Supabase, copy the project URL and a publishable key from Connect or API Keys. For a Vite frontend, the official React with Supabase guide uses VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY:

VITE_SUPABASE_URL=https://your-project.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

These values are bundled into browser code and visible to users; do not treat them as passwords. Supabase’s API keys guide says publishable keys identify a public app, while secret or service_role keys must never be sent to the frontend and bypass RLS. If the project still shows an anon key, use it only with appropriate policies and plan a transition to the new keys.

2. Check policies before exposing the app

A correct URL and publishable key do not by themselves authorize safe access. Enable and review Row Level Security on every table exposed through the Data API; define what each role can do, then test both signed-in and anonymous requests. Check Storage permissions and Edge Function endpoints too. Never put an admin key in VITE_*, a repository file or any variable exposed by the bundler.

3. Add the domain and redirects

Connect the repository to Projects, select the branch and define the public variables needed before the build. Vite replaces them at build time; redeploy if they change. Keep .env.local out of Git and do not copy secrets into logs.

In Supabase Auth, configure the primary site URL and add the redirect URLs you will actually use: the temporary domain, production and any callback routes required by your flow. Supabase’s redirect URL configuration must match the URLs your app generates. For OAuth, also check the callback URL registered with the external provider; it may differ from the page where the user lands afterward.

4. Test on the temporary domain before changing DNS

Open the app and verify allowed reads and writes, rejected unauthorized access, sign-in and sign-out, password recovery, OAuth, Storage and function calls. Check the browser console and Network panel; a successful build does not prove these integrations work. Review CORS or CSP if the browser blocks requests.

When everything works, point the final domain at Projects, update Supabase’s site URL and redirect allowlist, then repeat authentication flows over HTTPS. Keeping Supabase means its costs, quotas and availability still apply separately. If you also want to move data or Auth, plan and rehearse that migration as a separate project with a backup and rollback path.

Sources: React quickstart, API keys, secure data, redirect URLs and Projects.