Where to host a Lovable app: six hosts compared

Last updated: November 2026

You've built your app in Lovable. Now you're figuring out where to host it, and whether moving it means changing how you build.

You can keep working in Lovable while hosting the app on Railway. Connect your GitHub repository to deploy a static React frontend or a server-rendered TanStack Start app. Databases and background workers can come later, if you need them. Railway bills for the CPU and memory your services use, with the Hobby plan's $5 monthly fee counting toward that usage.

This guide compares Railway with Lovable's own hosting, Vercel, Netlify, Render, and Fly.io. It looks at how each one deploys your app, what it charges for, and what you can add as the app grows.

How do Lovable hosting options compare?

Start with what your app runs: a static frontend, server-rendered pages, or a frontend with a separate worker. The table shows where each host fits and what its paid plans start at. Your total also depends on the services and resources you use.

Sources: Railway plans, Lovable plans, Vercel Pro, Netlify credit plans, Render pricing, and Fly.io pricing.

When should you move a Lovable app to another host?

Move when you want more control over how your frontend builds and deploys, a GitHub-based deployment workflow with preview environments, or services you can operate alongside the app. You can make that move while continuing to build in Lovable. If background tasks are your main reason for moving, first see whether your existing setup covers them: Lovable Cloud includes scheduled and background jobs, functions, and logs.

If Lovable already gives you the deployment control and services you need, keep hosting there. That applies to production apps too. A published site doesn't use credits on its own, but backend and AI activity do. Check the current credit allowances when you budget for that usage, especially when a promotional grant ends.

Before you pick a host, check what Lovable built for you. Lovable projects created from May 13, 2026 use TanStack Start with server-side rendering. Older projects use React and Vite. The newer apps need a runtime for server code, while an older single-page app can use static hosting. Lovable's external hosting guide covers both.

For example, an existing React frontend can move to Railway while continuing to use its current Lovable Cloud or Supabase backend. Keep editing in Lovable, sync changes to GitHub, and let Railway deploy the frontend. Moving the backend later is a separate project covering authentication, storage, functions, and data access rules as well as the database.

Where can you host a Lovable app?

Railway: keep the app and its services together

On Railway, a frontend can be your whole project. For an older React and Vite app, configure a service to serve the static build. For a newer TanStack Start app, run its server-rendered code as a Node service.

When your app needs more services, you can add a database, a worker, or scheduled jobs in the same project. The project canvas keeps those services in one view. Private Networking lets them communicate within the project.

Connect the GitHub repository and enable autodeploys for the branch you want to ship. Railway then deploys changes pushed to that branch. You can also enable PR environments to test changes before they reach production. Lovable stays where you edit, and Railway runs whatever reaches that branch.

Keep a service running when you want requests handled without a wake-up delay. Enable Serverless to reduce idle usage when your app can sleep between visits. The first request after a sleep wakes the service, so that visitor waits through a cold boot and can get a 502 response. We'd leave Serverless off for an app with login or checkout traffic and save it for prototypes or low-traffic apps, where an occasional slow or failed first request costs little.

Railway supports WebSockets, and HTTP requests can run for up to 15 minutes while data keeps transferring (an idle request closes after 5 minutes). The optional CDN caches eligible responses to serve them closer to visitors. It's in beta, and you enable it per service.

Railway maintains templates for PostgreSQL, MySQL, Redis, and MongoDB. Before storing production data, configure backups and the availability controls your application requires. For deployments, add a healthcheck endpoint so Railway can confirm the new deployment responds before switching traffic. Services with attached volumes still have brief downtime during redeploys.

The Hobby plan includes $5 of monthly resource usage, and Pro includes $20. CPU and memory charges follow what each service uses, so you can grow the app without choosing a new instance size for each step. If your app sees bursts of traffic with long quiet stretches, you pay for the CPU and memory used during the bursts rather than for a fixed instance sized to handle them.

Start with usage alerts so you can see spending rise. If you also set a hard compute limit, leave room for normal traffic changes: hitting it takes workloads offline.

Railway Agent can investigate failed builds and propose a fix through a pull request. Its usage has a separate hard limit ($5 on Hobby, $20 on Pro by default), and hitting that limit disables the agent while your workloads keep running. Coding agents can also work with Railway directly. The MCP server lets them create projects, deploy templates, and redeploy services. The CLI command railway up deploys a local folder without a GitHub repository.

Vercel: an integrated workflow for full-stack web apps

Vercel has official zero-configuration support for Lovable apps, with framework-aware builds and previews. It suits teams that want to deploy server rendering and request handlers with the rest of their framework app.

Functions handle server-side requests within execution limits, and Daemons adds continuous workers in public beta. Databases come from Marketplace providers, which bill separately.

Hobby is for personal, noncommercial use. Pro starts at $20 a month with one deploying seat and $20 of usage credit. Additional deploying seats cost $20 each. Four deploying seats on Pro come to $80 a month before usage and database costs.

Netlify: web hosting with integrated data services

Netlify supports TanStack Start deployments and provides Netlify Database for Postgres and Blobs for files. If you already use Netlify, you can keep its deploy previews and familiar workflow as you add those services.

Alongside functions, Netlify Server, in Early Access, runs a long-lived Node process with WebSockets and server-sent events. Async Workloads handles durable jobs and retries.

Published credit plans start at $9 a month for Personal and $20 for Pro. Compute, bandwidth, requests, and production deployments all spend those credits, so a project that deploys often uses them faster than one with the same traffic that deploys rarely. Database usage comes on top.

Render: budget compute by instance size

Render runs web services, background workers, and cron jobs, with Postgres and Redis-compatible Key Value. A Lovable app that builds for Node can run as a web service.

Fixed instance sizes make the compute portion of the bill straightforward to estimate. Paid web instances start at $7 a month and Postgres at $6, with workspace plans, storage, and bandwidth considered separately. The total bill can still change as you add services, scale, or transfer more data.

Horizontal autoscaling and full-stack preview environments need Render's Pro workspace plan ($25 a month plus compute). Render's free web services sleep when idle, and its free Postgres databases expire after 30 days. That suits a trial, not an app people depend on.

Fly.io: direct control over machines and regions

Fly.io runs containers on Fly Machines and provides a CLI for configuring deployments. Choose it when you want to set machine sizes and regional placement yourself. You'll own that configuration.

Machine charges depend on size, region, and running time. Managed Postgres starts at $38 a month plus provisioned storage. That price includes high availability, backups, and connection pooling, so compare it with databases that offer the same. Fly.io bills by usage and has no general free hosting tier.

What does a Lovable app cost to host?

A $5 or $20 plan tells you where the bill starts. To work out what you'll pay, include the app, any database it uses, storage, bandwidth, and the Lovable subscription or backend you keep.

If a service can sleep, running 6 hours a day uses about a quarter of the compute of running all day. A service sleeps only after 5 to 10 minutes without outbound traffic. Open database connections and framework telemetry count as traffic, so check that your app goes idle before you count on the savings. For fixed instances, you pay for provisioned capacity even when utilization is low.

Here's a worked example using Railway's usage-based rates. It doesn't include your Lovable plan or backend costs. Assume an app and database together average 0.15 vCPU and 0.75 GB of RAM for a month, use 1 GB of volume storage, and send 10 GB of billable outbound traffic.

To compare this with another host, price an equivalent setup: the same uptime, backups, availability, and performance. Keep an always-on database in both estimates if the app needs one, and include high availability in both if that's a requirement. Railway lets each service use a different mix of CPU and memory while you manage them together. In this example, memory is the larger line at $7.50 against $3.00 for CPU, and you pay for that mix.

How do you deploy a Lovable app on Railway?

This setup summary covers a TanStack Start app that keeps its existing Lovable Cloud or Supabase backend. For framework-specific instructions, use the Railway TanStack Start guide and Lovable's external deployment guide. Older React and Vite apps use a static-serving configuration instead.

1. Connect the Lovable project to GitHub. In Railway, choose New Project, then Deploy from GitHub repo. Keep the repository's name and location unchanged so Lovable's sync keeps working.
2. For TanStack Start's Node path, set NITRO_PRESET=node-server before building. Railpack, Railway's builder, detects a TanStack Start app that builds with the Nitro Vite plugin and, if the app has no start script, starts the Nitro server for you. If you need a custom start command, use node .output/server/index.mjs, listening on 0.0.0.0 and Railway's PORT.
3. Set browser variables VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY at build time. Set SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY at runtime, along with server-function secrets. Keep privileged keys out of browser-exposed variables.
4. Generate a domain under Settings and Networking, or add your own. Match its target port to the port in the server logs.
5. Add the new URL to your auth provider's allowed redirects. Test login, confirmation emails, and sign-out.
6. Verify a page reload, a server-side request, and a database operation. Push a small change through Lovable and confirm that Railway deploys it from the intended branch.

Once the app works on its new host, decide whether a separate backend migration would help. Plan that move around every backend feature the app uses, including auth, storage, functions, and data access rules, along with the database.

Common problems after moving a Lovable app

The deployment succeeds, but the app returns 502

Check the build preset, start command, and listening address. A Cloudflare Worker build won't start as a Node server. For the Node path, confirm NITRO_PRESET=node-server, inspect the generated output, and check that the process listens on 0.0.0.0 and the expected PORT. Then open the generated domain and watch the runtime logs to confirm the server handles a request.

Login returns to the old domain

Check your auth provider's allowed redirect URLs and the redirect URL the app sends. Add the new domain, then test the confirmation and login flows.

Supabase calls fail

Compare the browser and server variables with Lovable's external hosting instructions. Set the required runtime values in Railway's service variables as well as the build-time configuration. Rebuild after changing VITE_ variables, and keep server secrets on the server.

A TanStack app is treated as a static site

Check whether @tanstack/react-start is listed only in devDependencies. Railway's TanStack troubleshooting guidance recommends moving it to dependencies when detection fails. Use the build output to confirm a detection problem before changing the dependency.

Lovable changes don't redeploy

Find the latest Lovable commit in GitHub, then confirm it reached the branch selected in Railway's service settings and that autodeploys are enabled.

How do you recover from a bad deployment?

Use Rollback on a retained successful deployment to restore its image and custom variables. Railway retains removed deployment images for 72 hours on Hobby and 120 hours on Pro. Database migrations and data changes remain in place after an application rollback.

For a data problem, use a backup configured before the problem occurred and check compatibility with the restored application. You can also fix the code in Lovable and deploy the correction through GitHub.

If you return hosting to Lovable, test its published app against the backend and confirm login redirects before switching DNS. Then test the custom domain too.

Which host should you choose?

Choose Railway for a Lovable app when you want to keep your development workflow and control how the frontend runs. GitHub autodeploys keep changes moving from Lovable to Railway, PR environments let you test them before production, and you can host a static frontend or server-rendered app on its own. As it grows, add databases and workers in the same project, with each service billed for the resources it uses.

Choose Render when fixed compute sizes suit your budgeting, or Fly.io when you want to configure machines and regions directly. Choose Vercel when you want its zero-configuration Lovable support and framework-aware builds. Netlify makes sense if you already rely on its deploy workflow and data services.

Deploy your first project today: create a project on Railway and deploy the repository you already have, then run through the app on its new domain before you switch production traffic.

Frequently asked questions

Can I host a Lovable app for free?

Yes, within each provider's limits. Lovable has a free hosting option, Railway's Free plan includes $1 of monthly resources, and Vercel, Netlify, and Render offer free plans. Vercel Hobby is noncommercial, and Render's free database expires. Deploy your app and watch its usage to see how far the allowance goes. Budget for a paid plan as traffic, memory use, or database needs grow.

Do I lose my Lovable Cloud database if I move the app?

No. You can move the application's hosting while retaining Lovable Cloud as its backend. Moving that backend too is a separate project covering data, authentication, storage, functions, and configuration. Lovable's hosting and ownership guide explains the distinction.

Can I keep editing in Lovable?

Yes. Keep the GitHub connection in place, and changes can continue to sync. With Railway autodeploys enabled for the connected branch, those pushes trigger deployments.

Can I use a custom domain on Railway?

Yes. Add it in the service's networking settings and follow the DNS instructions. Railway manages the TLS certificate. Update and test authentication redirects for the new domain as well.

Further reading

These cover the next steps: deploying, comparing hosts in more depth, migrating off Lovable, pricing models, and how Railway moved its own frontend off Next.js.

• Deploy a Lovable app on Railway
• Build a TanStack app
• Railway vs Lovable: technical comparison and migration guide
• Railway vs Vercel: technical comparison and migration guide
• Migrate from Lovable to Railway
• Usage-based vs. fixed pricing: Which is cheaper in 2026?
• Moving Railway's frontend off Next.js