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 solves for you.

How we host your app

Your app runs on Cloudflare's global edge network, present in 300+ cities worldwide. Staticbot reads your repository, sees a server-rendered app, and picks Cloudflare Workers for it. You then choose who owns the Cloudflare side.

Option 1: hosted by Staticbot (default)

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.

Option 2: hosted in your own Cloudflare account (coming soon)

You'll connect your Cloudflare account once in Staticbot, and the Worker will be deployed into your account, attached to your domain as a Worker Custom Domain in your own zone. Your existing Cloudflare DNS stays in charge, and the apex (yourdomain.com) will work directly. Staticbot will still build, deploy, redeploy, roll back, and remove the app for you. Previews stay on Staticbot's side.

In the first version, apps that need their own Cloudflare databases, key-value stores, buckets, or queues (D1, KV, R2, Queues) won't be supported on this option yet.

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.

If your domain's DNS is already on Cloudflare and connected to Staticbot, Staticbot can write these records for you after you approve. On the Staticbot-hosted option, a domain whose DNS is on Cloudflare uses www (or another subdomain) with the apex redirecting to it; hosting in your own Cloudflare account, once available, will serve the apex directly.

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 and audit it after. When hosting in your own Cloudflare account arrives, it won't use this Terraform at all: Wrangler will deploy the Worker and its Custom Domain straight into your account.

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, and whether you have a Lovable Cloud Data export.
2. Database — schema and data move to your target Supabase (managed by Supabase or self-hosted, your choice). With a Cloud Data export, Staticbot restores it directly, so users keep their passwords; otherwise it replays your migration files. You choose which.
3. Edge functions, storage, auth configuration — each one re-created on your own Supabase.
4. Preview — Staticbot deploys the migrated app to a preview URL against your new Supabase and health-checks it, so you can click through before anything changes for your users.
5. Switchover and frontend deploy — the new Supabase settings go on a separate staticbot/live branch, so Lovable keeps working on its own branch. Staticbot reads the repository and deploys a classic Vite project to AWS S3 + CloudFront, or a full-stack TanStack Start project to Cloudflare.

If people already use your app, treat this first run as a test migration. The live migration guide covers the rest: a short maintenance window, a fresh final copy, and reopening on your domain. After that, Continuous Sync gives every change you make in Lovable a checked preview before it 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.