Frontend Hosting for Supabase Apps
You have a Supabase backend (Cloud or self-hosted) and need somewhere to deploy the frontend. Staticbot picks the right target based on your project type, injects your Supabase URL and anon key at build time, and sets up your custom domain. Looking to host the Supabase backend itself? See Supabase hosting on AWS.
Staticbot detects what your project is and picks the right path
Staticbot reads your repo and recommends the deploy target that fits — you can still pick yourself if you'd rather. Two clean buckets:
Full-stack / SSR
→ Cloudflare WorkersTanStack Start (Lovable's new default), Nuxt 3, SolidStart, Astro with the CF adapter, bare Hono Workers — anything that builds for the Cloudflare runtime.
- →Server-side rendering + server functions
- →Server-only env vars (kept off the client bundle)
- →Custom domain via SSL for SaaS — no nameserver migration
- →Global edge in 300+ cities
Static / SPA
→ AWS S3 + CloudFrontClassic Vite + React SPAs, plain HTML/CSS/JS, JAMstack builds — anything that produces a folder of files to serve.
- →S3 origin + CloudFront global CDN
- →Build-time injection of public env vars (
VITE_SUPABASE_URL, anon key) - →ACM cert, www → apex redirects, all wired
- →Permanent 1 TB/mo CloudFront free tier
Managed by Staticbot, or in your own cloud account
Once Staticbot picks the target, you choose who owns the underlying cloud account:
Staticbot-managed account
Zero setup — point your domain, click deploy. Staticbot's account, Staticbot's billing. Best for getting to production fast.
Available today for AWS and Cloudflare.
Your own cloud account
Connect your account; Staticbot orchestrates the deploy with no platform fee. You own the data, the keys, the billing.
- AWS: available today
- Cloudflare: coming soon
How Supabase env vars get into your app
Staticbot auto-detects Supabase environment variables from your repo (SUPABASE_URL / SUPABASE_ANON_KEY and their VITE_ / NEXT_PUBLIC_ variants) so you can manage them in the dashboard without editing .env files in the repo.
- Static / SPA: public env vars get baked into the bundle at build time. Supabase's anon key is safe to ship to the browser — Row Level Security is what protects your tables.
- Full-stack / SSR: public env vars (
VITE_*prefixed) ship to the client; server-only env vars stay server-side and are pushed to Cloudflare's secret store at deploy time — never in source control, never in deployment logs.
Service role key (SUPABASE_SERVICE_ROLE_KEY) on the static path is not supported — there's no server-side runtime to keep it secret. Use the full-stack path or move that logic into a Supabase edge function.
Continuous deployment on autopilot
Connect your GitHub repo once. Every push to your main branch triggers a rebuild and redeploy on whichever target Staticbot picked for you. If you came from Lovable, Bolt, or Base44, the changes you push from the builder flow through automatically — no re-migration, no copy-paste.
Migrating from Lovable Cloud?
Staticbot automates the full backend migration into a Supabase project you own — database schema, edge functions, storage buckets, auth users with OAuth identities, secrets, and cron jobs — and deploys the frontend in the same run. Full-stack TanStack Start projects (Lovable's default since May 2026) land on Cloudflare; classic Vite SPAs land on AWS. One guided flow, ~15 minutes.
Explore the automated migration guideGet Started Now
Connect your repo, point your domain, and ship — first migration credit is free.
View Supabase Deployment Guide