Lovable Nitro Cloudflare Vercel Preset Incompatibility
Lovable uses Nitro with Cloudflare Workers preset by default. Learn why this breaks Vercel deployments and fix it with a simple vite.config.ts change.
- Lovable migrated to TanStack Start in May 2026, replacing the client-side SPA model with a Nitro-based full-stack runtime
- Nitro presets abstract different platforms: the default Cloudflare Workers preset breaks Vercel deployments without configuration changes
- Fix Vercel deployment by changing the preset from 'cloudflare-workers' to 'vercel' in vite.config.ts and removing conflicting config files
- Cloudflare Pages works with zero configuration, while Vercel requires environment variable setup and preset changes
- Each platform has distinct trade-offs: Vercel is regional with per-request billing, Cloudflare is global edge with cheaper scale pricing, DIY hosting is cheapest but requires ops expertise
Lovable switched to TanStack Start with Nitro in May 2026, which changed how apps deploy. The default Cloudflare Workers preset breaks Vercel deployments because Nitro assumes a Cloudflare runtime unless you explicitly reconfigure it. This guide explains why this happened and how to deploy to Vercel, Cloudflare Pages, or Workers correctly.
What Changed in Lovable (May 2026)
Until May 2026, Lovable shipped apps as client-side React SPAs: you exported a bundle, pushed it to any static host (Vercel, Netlify, GitHub Pages), and it worked. That model is gone.
Lovable moved to TanStack Start, a full-stack React framework built on top of Nitro, the universal JavaScript runtime by the Nuxt team. TanStack Start lets you write server-side rendering (SSR) functions in your Lovable app. Database queries, authentication, file uploads happen on a server now, not the browser.
This is a hard win for SEO and performance. Google crawls real HTML instead of JavaScript shells. But it forces a deployment choice: which platform will run your server? That choice matters because Nitro uses "presets" to adapt your code to different runtimes.
Lovable chose Cloudflare Workers as its default preset. That works perfectly for Cloudflare, but it breaks Vercel, Netlify, and DIY servers without explicit configuration.
Why Nitro Presets Matter
Nitro is a framework-agnostic runtime abstraction. It lets you write server code once and deploy to Cloudflare Workers, AWS Lambda, Node.js servers, or a dozen other platforms. But each platform has different constraints: Workers runs on Cloudflare's global edge with 30-second timeouts and no persistent disk. Lambda runs regionally with 15-minute timeouts. Node.js servers run wherever you install them.
Nitro handles these differences via "presets." A preset is a build configuration that outputs code tailored to a specific platform's API. The Cloudflare preset outputs a handler compatible with the Cloudflare Workers JavaScript API. The Vercel preset outputs a handler that works with Vercel Functions. Same code, different output.
Lovable's generated vite.config.ts file includes a preset comment that tells Nitro which platform to target during build. If you don't change it, Nitro assumes Cloudflare Workers.
The Root Cause: Nitro Preset Mismatch
When you export a Lovable app, the vite.config.ts includes this line (or equivalent):
// nitro.config: preset = "cloudflare-workers"
This tells Nitro to build server code assuming the Cloudflare Workers runtime. If you then push this export to Vercel without changing the preset, Nitro outputs Worker-specific code. Vercel's deployment system tries to run Worker code on Vercel Functions, which have a completely different API. Functions can't find the Worker imports, the build fails, or you get a 404 on every API route.
Cloudflare Pages has a similar issue but includes a fallback: if you deploy Worker code to Pages, it detects the Worker runtime and automatically uses Cloudflare's Wrangler toolchain. That's why switching to Cloudflare Pages is the path of least resistance. Lovable's export already assumes that environment.
Vercel, Netlify, and traditional servers don't have this fallback. They need the preset explicitly changed.
Deploying to Vercel: Step by Step
Vercel hosting requires the Nitro Vercel preset. Here's how to make it work:
- Open vite.config.ts in your Lovable export directory.
- Change or add the Nitro preset line:
// nitro.config: preset = "vercel" - Install Vercel preset dependencies (if not already installed):
npm install nitro-preset-vercel - Delete wrangler.toml or wrangler.jsonc if it exists. This file tells Node.js tooling to expect Cloudflare Workers. It will conflict with Vercel's build process.
- Update package.json build script if needed. Lovable exports usually have:
This should remain unchanged. Nitro auto-detects the preset from vite.config.ts."build": "vite build" - Set environment variables in Vercel: Any secrets your app uses (database URLs, API keys) go into the Vercel project settings under Environment Variables. Vercel propagates these to Functions at runtime.
- Push to GitHub and deploy. Vercel will rebuild with the Vercel preset, output Functions instead of Worker code, and your routes will work.
Common errors and fixes:
- "Module not found: @cloudflare/workers-types" You still have the old preset. Verify vite.config.ts says
preset = "vercel". - "404 on /api/...routes" Environment variables aren't set. Check Vercel project settings and redeploy after adding them.
- Build times out Vercel Functions have resource limits. If your app needs heavy computation, consider Cloudflare Workers instead (higher compute allowance).
Deploying to Cloudflare: Workers vs. Pages
Cloudflare has two deployment options for full-stack apps: Cloudflare Pages (simple) and Cloudflare Workers (advanced).
Cloudflare Pages is the easier path. Pages is a managed platform for deploying full-stack Nitro apps. You link your GitHub repo, Pages detects the TanStack Start / Nitro app, and handles the build and deployment automatically. The Cloudflare Workers preset that Lovable ships with is built for Pages. Deploy to Pages and your app works with zero additional configuration. No vite.config.ts changes needed. This is why Cloudflare Pages is often recommended as the simplest migration from Lovable Cloud.
Cloudflare Workers is for developers who need fine-grained control or want to deploy outside the Pages CI/CD pipeline. Workers runs code on Cloudflare's global edge network. You use wrangler (Cloudflare's CLI tool) to build and deploy directly. The Workers preset is also built-in, but you manage the wrangler.toml or wrangler.jsonc file for configuration (KV namespaces, R2 buckets, cron triggers, etc.). Workers is more powerful but requires more setup.
When to choose each:
- Pages: You're coming from Lovable Cloud. You want the simplest path. You don't need scheduled jobs or cron triggers. Free tier is enough (100,000 requests/day).
- Workers: You need more requests, scheduled jobs (cron triggers), edge middleware, or you want to integrate Cloudflare's full platform (R2 for storage, KV for cache, Queues for background jobs).
If you're unsure, start with Pages. Switching to Workers later is straightforward; both use the same code.
Trade-offs: Vercel vs. Cloudflare vs. DIY
You have three deployment paths. Each has trade-offs.
Vercel runs apps on regional servers (US East, Europe, Asia via edge caching for static content). Compute is priced per invocation: free tier covers 1 million requests/month, then $0.50 per 1 million requests (exact rates vary by region). Vercel Functions have a 900-second timeout, so long-running tasks need separate queue services. Integration with the Vercel ecosystem (analytics, edge config, Postgres) is tight. Vendor lock-in is real: your server code is tied to Vercel's Function API. Switching later requires migrating environment variables and re-architecting for the new platform's compute model.
Cloudflare Workers runs on a global edge network; your code executes in the data center closest to the user. This means faster response times for most users. Free tier includes 100,000 requests/day. Paid: $0.50 per 10 million requests (much cheaper at scale). Workers has a 30-second timeout, which suits most APIs but breaks long-running jobs. Cloudflare integrates storage (R2), caching (KV), and databases (D1) into one platform. Vendor lock-in exists but is less severe: the Cloudflare preset is standard (Nitro, TanStack Start, others all support it). Code is more portable.
DIY hosting (Hetzner + Coolify, or any VPS + Docker) means you run Node.js on your own servers. Cost is predictable and cheap: a 2vCPU/4GB RAM box from Hetzner costs $6/month. No per-request billing. You own the infrastructure, so no vendor lock-in. But you manage everything: deployments, auto-scaling, monitoring, backups, SSL certificates. This is the cheapest option at massive scale but the most expensive in developer time at small scale. Most Lovable users don't have the ops depth for DIY hosting.
For a typical Lovable app (< 1 million requests/month), Vercel and Cloudflare Pages cost roughly the same and stay free. If your app grows, Cloudflare's per-10-million-request pricing wins. Vercel wins if you need tight integration with their ecosystem or scheduled jobs that Workers' 30-second limit won't allow. See our cost comparison across hosting platforms for more detail.
When to Stay on Lovable Cloud
Lovable Cloud is Lovable's managed hosting. You deploy with one click; Lovable handles infrastructure, scaling, and updates. It costs $50-300/month depending on traffic tier.
The trade-off: you're locked into Lovable's platform. You can't customize the runtime, integrate your own Cloudflare resources, or switch without exporting and redeploying.
When does that make sense? If you're prototyping, Lovable Cloud is unbeatable. If you're scaling a real product and need predictable billing and fine-grained control, exporting to Vercel or Cloudflare is smarter. The export process takes an hour; you recoup that time within your first billing cycle if you avoid Lovable's premium tiers.
Lovable Cloud is best for: MVPs, founder-led projects, teams with no ops experience. Vercel or Cloudflare is best for: anything heading to customers, apps with >100k monthly requests, teams comfortable with infrastructure.
Ship: The Managed Hosting Alternative
If you've exported Lovable but don't want to manage Vercel or Cloudflare directly, Ship by Opsily offers a middle ground. Ship provides managed hosting for full-stack JavaScript apps (including Lovable/TanStack Start exports) on predictable, transparent pricing. You deploy via Git; Ship handles the Nitro configuration, environment variable management, and scaling. No vendor lock-in: the app code and database remain yours. You can self-host or move to another provider anytime.
Ship costs $20-150/month depending on usage (vs. Vercel's $0-unlimited with per-request billing and Cloudflare's free-tier limits). The draw is predictability: you know your bill upfront, no surprises from traffic spikes. For founder-led projects and small teams, this removes the operational overhead of learning Vercel or Cloudflare while keeping the cost-control of self-hosting.
This guide focused on Vercel and Cloudflare because they're the most common destinations for Lovable exports. If you want more details on the full export process, see our step-by-step guide to deploying Lovable apps.
Frequently Asked Questions
Can I use Cloudflare with Lovable?
Yes. Lovable's default preset is Cloudflare Workers, so your exported app works on Cloudflare with zero configuration changes. Deploy to Cloudflare Pages (simplest) or use Cloudflare Workers directly (more control). No code changes needed.
How do I remove Cloudflare restrictions?
Cloudflare Workers has a 30-second execution timeout and no persistent disk. If your app hits these limits, migrate to Vercel or traditional hosting. For Workers-specific issues, check Cloudflare's documentation on increasing timeout via scheduled jobs or breaking work into queues.
How does Lovable deploy?
Lovable exports a full-stack TanStack Start / Nitro app. You choose where to deploy: Lovable Cloud (managed), Vercel, Cloudflare, or DIY hosting. The export contains a vite.config.ts that specifies the Nitro preset. Change the preset to target a different platform.
Why does the Lovable Nitro Cloudflare Workers preset fail on Vercel?
Nitro defaults to the Cloudflare Workers preset when you export a Lovable app. Vercel can't run Worker-specific code; it expects the Vercel preset. Change vite.config.ts from preset = "cloudflare-workers" to preset = "vercel" to fix it.
Should I stay on Lovable Cloud or export?
If you're prototyping with less than 10k monthly requests, Lovable Cloud is simpler. If you're going live with real users, exporting to Vercel or Cloudflare gives you more control and often lower costs.
Is there a managed option between Lovable Cloud and DIY hosting?
Yes. Managed hosts like Ship, Staticbot, and Render offer turnkey hosting for full-stack JavaScript apps. They handle Nitro configuration and scaling for a flat monthly fee, avoiding per-request billing surprises.
The Bottom Line
Lovable's May 2026 switch to TanStack Start and Nitro changed deployment forever. The Cloudflare Workers default preset works seamlessly on Cloudflare Pages and Workers, but not Vercel, Netlify, or traditional servers without configuration changes. The fix is simple: change the Nitro preset in vite.config.ts, remove conflicting config files, and redeploy.
For most founders and small teams, Vercel and Cloudflare Pages are free or nearly free, so there's no downside to experimenting. Cloudflare Pages is the fastest to deploy if you want to stay on Cloudflare. Vercel wins if you need long-running functions or tight ecosystem integration. DIY hosting is cheapest at scale but requires ops skills.
If you want infrastructure handled for you, Ship provides managed hosting for Lovable apps with transparent, predictable pricing and zero vendor lock-in.