Deploying Lovable TanStack Start Apps to Cloudflare Workers

What actually changed for your project

Before May 13, every Lovable project was a single-page React app. The build produced a folder of HTML, CSS, and JavaScript. Drop it on a CDN, point your domain at it, done. That's how Lovable apps were hosted up until then, and that's how Staticbot's existing deploys work.

New Lovable projects are different. The build still produces files, but it also produces a small server program that runs on every request — drawing data, rendering pages, running server-only logic. Lovable's announcement explains the why: faster first paint, better SEO, server-only secrets, and the AI can put backend logic right next to your components.

The catch is that this server program can't live on a plain file CDN. It needs to run somewhere, fast, on every request, from every country your users come from. That's the problem Staticbot quietly solves for you.

How we host your app

Your app runs on Cloudflare's global edge network — the same one Cloudflare uses for its own products, present in 300+ cities worldwide. We use a Cloudflare product called Workers for Platforms, which is built exactly for cases like ours: a SaaS provider hosting customer apps side-by-side, each isolated from the others, each with its own domain.

When a request hits your domain, Cloudflare terminates the connection at the nearest edge city, looks up which customer's app to dispatch to, and runs your code. The lookup and dispatch happen in single-digit milliseconds. Your app doesn't compete for capacity with other customers because Cloudflare gives each one its own isolated runtime.

You never see a Cloudflare login. You don't manage the Workers account, the routing, or the configuration. Staticbot owns the operational side; you own the app and the data.

Your domain, your registrar, no migration

Your domain stays where it is. Namecheap, GoDaddy, Google Domains, Route 53, Cloudflare-as-registrar — wherever you bought it. You don't move nameservers, you don't transfer the domain, and you keep full ownership.

What you do is add a small number of DNS records that Staticbot generates for you and shows in the deployment screen with copy buttons:

• An ALIAS (or ANAME) at the apex (yourdomain.com), or a CNAME on a subdomain (www.yourdomain.com or app.yourdomain.com). See our guides for adding an ANAME/ALIAS record or adding a CNAME.
• One TXT record so Cloudflare can verify you control the domain and issue your SSL certificate.

Most modern registrars support ALIAS / ANAME at the apex — Namecheap, Route 53, DNSimple, Cloudflare-as-registrar, Hover, deSEC, and others. If yours doesn't (a handful of older or budget registrars still don't), the deployment screen shows you the alternative: use www as your canonical hostname and set the apex to redirect — a feature every registrar offers for free, and a pattern Vercel, Netlify, Heroku, and most other modern hosts document and support natively.

SSL is fully automatic. Cloudflare issues the certificate, renews it before expiry, and serves modern TLS. There's no certificate setup on your end and nothing to remember to rotate.

Our deployment code is open source

Two things matter for trust: what we promise, and whether you can verify it. The infrastructure code that runs to set up your hosting — the Terraform module, deliberately small and readable — is open source in the public github.com/bitfiction/staticbot repo under infrastructure/_templates/cloudflare_workers_app_template/.

Per customer, it provisions two things on Cloudflare: your custom hostname (with the SSL cert) and the routing entry that maps your domain to your app. That's the entire footprint — under 100 lines of Terraform. You can read it before you commit, you can audit it after, and you can fork it when you bring your own Cloudflare account later.

The same setup handles TanStack Start (Lovable's current default), Nuxt 3, SolidStart, Astro (with the Cloudflare adapter), and Hono Workers — the build details are configurable per stack, not baked into the infrastructure. You commit code in any of those frameworks; Staticbot picks the right build profile.

What happens when you click Deploy

Four steps. You see each one move through the Staticbot dashboard, with live status:

1. Set up your domain on the edge. Staticbot creates the custom-hostname entry on Cloudflare and surfaces the DNS records you need to add. The SSL certificate is requested automatically.
2. Build your app from your repo. Staticbot pulls your code from GitHub, detects your Node version and package manager from the files you committed, installs dependencies, and runs your build. No build server to configure.
3. Deploy to Cloudflare. The built app is shipped to your isolated runtime on the edge. Sensitive environment variables (API keys, secrets) are pushed separately into Cloudflare's secret store — they never sit in source code or in deployment logs.
4. Verify it's responding. Staticbot polls your public URL until it returns a healthy response. This is informational — DNS and certificate propagation can take a few minutes, and we don't want a green deploy to flip red just because your DNS is still warming up.

Same orchestration we use for Supabase migrations and static-site deploys — no new framework, no new mental model.

Migration from Lovable: backend + app, one run

If you're on Lovable Cloud (the bundled Supabase that comes with Lovable), Staticbot migrates everything in one guided flow:

1. Inventory — Staticbot scans your Lovable Supabase: schema, tables, edge functions, storage buckets, auth configuration.
2. Database — schema and table data move to your target Supabase (managed by Supabase or self-hosted, your choice).
3. Edge functions, storage, auth configuration — each one re-created on your own Supabase.
4. Switchover — Staticbot updates the Supabase URL and key in your GitHub repo so the deployed app talks to your Supabase. Your Lovable preview keeps using Lovable's; the live app at your domain uses yours.
5. Frontend deploy — Staticbot auto-detects whether you have a classic Vite project (deploys to AWS S3 + CloudFront) or a new full-stack TanStack Start project (deploys to Cloudflare). The deploy runs. Your app goes live.

If your project predates the May 13 cutover and is still on Vite + React, the existing AWS S3 + CloudFront path is unchanged. Same dashboard, same migration, different deploy target. Nothing about the choice is sticky — if Lovable ships another stack tomorrow, we add another template, you re-deploy.