Lovable 應用如何透過 Coolify 部署到自有伺服器

You can move a Lovable app onto your own server with Coolify: point Coolify at the GitHub repo Lovable syncs to, build it as a static Vite site with dist as the publish directory, add one Nginx line so page refreshes don't 404, and put your domain on it. As of October 2026 self-hosted Coolify is free, Coolify Cloud is $5 a month for up to two servers, and the server itself is the real bill (Hetzner's CAX21, 4 ARM cores and 8 GB, is €10.49 a month after their June price rise).

That moves the front end. Whether it moves the whole app depends on where your database lives, and that's the part most "self-host Lovable" threads skip.

What actually moves

A Lovable project is two things wearing one name. There's the React app Lovable writes (Vite, TypeScript, Tailwind), which compiles to a folder of static files. And there's the backend: on Lovable Cloud that's a Supabase project Lovable runs for you, with your tables, auth users, storage buckets and edge functions.

Coolify takes the first one easily. The second one stays exactly where it is unless you move it on purpose. So after a Coolify deploy you have your own server serving the pages, and the pages still talk to Lovable Cloud for every login and every query. That's a perfectly good setup if what you wanted was your own hosting, your own headers and no Lovable badge. It is not "off Lovable".

If you want the data on your side too, there are two roads. Move it to a Supabase project you own (that's the Cloud to Supabase migration we do in 1 to 2 days), or run self-hosted Supabase as a Coolify service on the same box. The second one is cheaper on paper and more work forever after: you own the backups, the Postgres upgrades and the 3 a.m. disk alert. Lovable also can't manage a self-hosted database, so new tables and policies become a developer's job instead of a chat message.

The Coolify settings that work for a Lovable repo

Coolify's own minimum is 2 CPU cores, 2 GB of RAM and 10 GB of disk, on Ubuntu, Debian or most other Linux distributions, amd64 or arm64. The install is one command on a fresh server:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

It prints the next steps when it finishes. Then, in the dashboard:

1. Add a new resource from your GitHub repo (install Coolify's GitHub App so it gets push webhooks; Lovable's GitHub sync pushes to the default branch, so every Lovable edit redeploys).
2. Build pack Nixpacks, Site type Static, Publish directory dist.
3. Add your VITE_ variables if the repo doesn't already carry them in .env. In Coolify's environment variables screen, leave Build time set to Available during build, because Vite bakes these into the JavaScript at build time. A variable that's only available at runtime does nothing for a static site.
4. Generate the Nginx config under General and add the single-page fallback (below), then deploy.
5. Add your domain and let Coolify's proxy fetch the certificate.

The refresh 404 everyone hits once

Lovable apps use client-side routing. Nginx doesn't know that. Open /dashboard from the home page and it works, because React Router handled it in the browser. Hit refresh on /dashboard and Nginx looks for a file called dashboard, finds nothing and returns its plain white "404 Not Found" page.

The last founder who showed me this had already blamed Cloudflare, then the DNS, then Coolify. It's one line in the location / block:

try_files $uri $uri/ /index.html;

Coolify copies the Nginx config into the image at build time, so you have to redeploy after changing it. A restart reuses the old image and the 404 stays, which is a fun extra hour if nobody tells you.

What it costs, honestly

For the front end alone, self-hosting saves less than people expect. Static files are cheap to serve anywhere, and Lovable's own hosting is included in the plan you're probably keeping anyway, because you still build in Lovable. The money starts to matter when the backend moves too: a Lovable Cloud instance at the bigger sizes costs more per month than a whole 8 GB server running Coolify plus self-hosted Supabase.

So here's my actual opinion. If your Lovable Cloud bill is small, don't self-host for the money. Do it if you need control (headers, a region, a server you can SSH into, one bill for several apps). If the bill is large, move the backend first, because that's where the savings are, and decide about the front end after.

Not sure which camp you're in? The free Lovable cost check reads your repo and prices four ways forward, including the Coolify server route, next to what you pay now.

Things that break after the move

Auth redirect URLs are the big one. Supabase only sends magic links and OAuth callbacks to URLs on its allow list, and your new domain isn't on it until someone adds it. Do that before you switch DNS, not after the first user writes in saying the login link opens the old site.

Edge functions don't come along. They keep running where your backend runs, and the front end on Coolify calls them there, which is fine until you move the backend and forget them.

And Lovable's preview keeps working, because it never needed your server in the first place. That's handy: you keep building in Lovable, push, and Coolify ships it a minute later.

If you would rather have someone set this up with the database move done properly, that is a fixed-price job for us: your Lovable app on your own server is $500 to set up, plus the Cloud move if you need it. Or tell us about your app.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.