How to deploy a Lovable app to production (with a real backend)
Lovable builds the app; the wall is getting it live with a backend. Export your project’s code, then publish the folder to shiply in one call — live URL, database, and domain, at a flat price.
The short version: Lovable is great at building the app — but it stops at a folder of code. To get that live with a real backend, export your project’s code (Lovable supports GitHub sync and a code download), then publish the folder to shiply in one call. You get a live URL, a SQL database, server functions, email, and a custom domain — at a flat price, with no usage meter counting every request. That is the whole flow. The rest of this post is the detail.
Lovable builds the app. The wall is production.
You described the app, Lovable generated it, and it works in the preview. Then comes the question that stalls almost everyone: “now how do I actually get this live — with a backend?” A preview URL is not production. A real app needs somewhere to serve it, a database to hold its data, a place for server-side logic, and a domain people can trust. The usual answer is to go stitch together a host, a database provider, an email service, and a registrar — four vendors, four dashboards, four bills — before anything is live. That assembly step is the wall.
It does not have to be. If the app is already built, most of that ceremony buys you nothing. You do not need a remote build pipeline or an account wizard. You need a way to hand the built files to a server and get a URL back — with the backend pieces already attached.
Step-by-step: from Lovable to a live URL
- Export your project’s code. Lovable lets you get the underlying code out of the builder — either by syncing the project to a GitHub repository or by downloading the code. Use whichever you already have set up. The goal is a local folder (or a repo you can clone) containing the app’s source.
- Build it locally. Install dependencies and run the project’s build (
npm install, thennpm run build). This produces the output directory the app actually serves from — typicallydist/orbuild/. For a Vite + React app like this, publishing the finisheddist/is the reliable path: you bring the built output and shiply serves it from the edge. - Publish the folder to shiply. Point the CLI at the built directory:
npx shiply-cli publish ./distIt prints a live URL. One detail worth getting right: the npm package is shiply-cli, not shiply — a different, unrelated package owns the bare name. If your agent (Cursor, Claude Code, or the like) is doing the work, it can run the exact same command, or paste the publish prompt from the host-your-cursor-project guide and let the agent publish without you touching a terminal. Either way, the site goes live at <slug>.shiply.now on Cloudflare’s edge. It starts anonymous and free — you claim it to keep it, which also creates a free account if you do not have one yet.
What about the backend?
A live URL is only half of production. The other half is the stack behind it, and that is the part shiply is built to include rather than send you shopping for:
- Database. Per-site SQL — a D1 database or Neon Postgres — so your app has somewhere real to store data, not a mock.
- Server functions. Per-site edge functions on Cloudflare Workers for the logic that cannot live in the browser — handling a form, calling an API with a secret key, running a webhook.
- Email. Transactional email built in, so sign-up confirmations and notifications work without wiring a separate provider.
- Custom domain. Attach your own domain with automatic SSL, so the app lives on a URL your users trust instead of a subdomain.
One honest caveat on frameworks: shiply runs server-side rendering for every major JS framework — SvelteKit, Astro, Qwik, the Nitro family, React Router v7, and Next.js (plain SSR via OpenNext). Most Lovable projects are a Vite + React single-page app, which shiply serves cleanly. What it does not yet do is Next.js ISR / on-demand revalidation. If your specific app leans on that, check the framework support first — but for a typical Lovable build, you are well inside what shiply serves.
What it costs
The pricing is flat and you can read it off the card: $0, $8, or $24 a month. There is no usage meter underneath — your bill does not move because a crawler hammered your site or a post did numbers overnight. That is the deliberate difference from metered hosts, where traffic you do not control shows up on your invoice. If you want to sanity-check the number against your real usage, the hosting cost calculator does the math, and the shiply vs Vercel comparison lays out flat-versus-metered side by side.
FAQ
Can I host a Lovable app somewhere other than the Lovable preview? Yes. The Lovable preview is for building; for production you export the project’s code and host the built app wherever you like. Publishing the built folder to shiply gets you a live URL plus the backend in one step.
Do I need to move my database? If your app already uses an external database, keep it — point the app at it via environment variables. If you do not have one yet, shiply gives you a per-site SQL database so you do not have to add another vendor.
Does my agent have to do this, or can I? Either. The CLI is one command in a terminal. If an agent built the app, it can run the same publish itself, so the flow never leaves the chat.
What happens to the free URL? An anonymous publish is live immediately and free, and expires after 24 hours unless you claim it. Claiming moves it into an account and makes it permanent — the trial costs nothing and leaves nothing behind.
The short version, again
Lovable takes you from an idea to a working app. The gap it leaves is production: a live URL, a database, functions, email, a domain. Export your project’s code, build it, and publish the folder to shiply in one call — the backend comes attached, and the price stays flat. If you want the same path from another agent, the Cursor guide covers it, the Bolt.new version mirrors it for Bolt projects, and the shiply.now homepage has the one-command version.