Lovable on Coolify: Host It on Your Server

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).

你可以使用 Coolify 将 Lovable 应用迁移到自己的服务器上：将 Coolify 指向 Lovable 同步的 GitHub 仓库，将其构建为发布目录为 dist 的静态 Vite 站点，添加一行 Nginx 配置以防止页面刷新出现 404 错误，并绑定你的域名。截至 2026 年 10 月，自托管 Coolify 是免费的，Coolify Cloud 每月 5 美元最多支持两台服务器，而服务器本身的费用才是大头（Hetzner 的 CAX21，4 核 ARM 和 8GB 内存，在 6 月涨价后每月 10.49 欧元）。

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.

这只是迁移了前端。整个应用是否完成迁移取决于你的数据库存放在哪里，而这正是大多数“自托管 Lovable”讨论帖所忽略的部分。一个 Lovable 项目实际上由两个同名的部分组成。一个是 Lovable 编写的 React 应用（Vite、TypeScript、Tailwind），它会被编译成一个静态文件文件夹。另一个是后端：在 Lovable Cloud 上，这是一个由 Lovable 为你运行的 Supabase 项目，包含你的数据表、认证用户、存储桶和边缘函数。Coolify 可以轻松处理前者，但除非你刻意迁移，否则后者会留在原地。

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.

因此，在 Coolify 部署完成后，你拥有了自己的服务器来提供页面，但这些页面在每次登录和查询时仍会与 Lovable Cloud 通信。如果你只是想要自己的托管服务、自定义请求头且不显示 Lovable 徽标，这完全没问题。但这并不意味着“脱离了 Lovable”。如果你也想把数据掌握在自己手中，有两条路可选：将其迁移到你拥有的 Supabase 项目（这是我们 1 到 2 天内完成的 Cloud 到 Supabase 迁移服务），或者在同一台机器上将自托管的 Supabase 作为 Coolify 服务运行。后者在账面上更便宜，但后续维护工作量巨大：你需要负责备份、Postgres 升级以及凌晨 3 点的磁盘报警。

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: 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).

适用于 Lovable 仓库的 Coolify 设置：Coolify 本身的最低配置要求是 2 核 CPU、2GB 内存和 10GB 磁盘空间，支持 Ubuntu、Debian 或大多数其他 Linux 发行版（amd64 或 arm64）。在全新的服务器上，只需一条命令即可安装：curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash。安装完成后，它会打印出后续步骤。然后，在仪表板中：从你的 GitHub 仓库添加一个新资源（安装 Coolify 的 GitHub App 以获取推送 Webhook；Lovable 的 GitHub 同步会推送到默认分支，因此每次 Lovable 编辑都会触发重新部署）。

Build pack Nixpacks, Site type Static, Publish directory dist. 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. Generate the Nginx config under General and add the single-page fallback (below), then deploy. Add your domain and let Coolify’s proxy fetch the certificate.

构建包选择 Nixpacks，站点类型选择 Static，发布目录设置为 dist。如果仓库的 .env 文件中没有包含 VITE_ 变量，请手动添加。在 Coolify 的环境变量界面中，将构建时间设置为“在构建期间可用”（Available during build），因为 Vite 会在构建时将这些变量写入 JavaScript。仅在运行时可用的变量对静态站点无效。在“常规”（General）下生成 Nginx 配置，添加单页回退（见下文），然后部署。绑定你的域名，让 Coolify 的代理获取证书。

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.

每个人都会遇到的刷新 404 问题：Lovable 应用使用客户端路由，而 Nginx 并不知道这一点。从主页打开 /dashboard 可以正常工作，因为 React Router 在浏览器中处理了它。但在 /dashboard 页面刷新时，Nginx 会寻找名为 dashboard 的文件，找不到就会返回纯白色的“404 Not Found”页面。上一位向我展示此问题的创始人已经先后责怪了 Cloudflare、DNS 和 Coolify。其实只需在 location / 块中添加一行：try_files $uri $uri/ /index.html;。Coolify 会在构建时将 Nginx 配置复制到镜像中，因此修改后必须重新部署。重启只会重用旧镜像，404 问题依然存在，如果没人告诉你，这会让你多花一小时排查。

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.

老实说，成本如何：仅就前端而言，自托管节省的费用比人们预期的要少。静态文件在任何地方托管都很便宜，而且 Lovable 的托管服务通常包含在你可能已经在使用的套餐中，因为你仍然需要在 Lovable 中进行构建。只有当后端也迁移时，成本差异才会显现：大型 Lovable Cloud 实例的月费比运行 Coolify 加自托管 Supabase 的 8GB 服务器还要贵。所以我的真实建议是：如果你的 Lovable Cloud 账单很小，不要为了省钱而自托管。只有当你需要控制权（自定义请求头、特定区域、可 SSH 的服务器、多个应用合并账单）时才这样做。如果账单很高，先迁移后端，因为那才是省钱的关键，然后再决定是否迁移前端。

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.

不确定自己属于哪种情况？免费的 Lovable 成本检查工具会读取你的仓库，并对比你当前的支出，列出四种未来的定价方案，包括 Coolify 服务器路线。迁移后会损坏的东西：认证重定向 URL 是个大问题。Supabase 只会将 Magic Link 和 OAuth 回调发送到其允许列表中的 URL，而在有人添加之前，你的新域名不在列表中。请在切换 DNS 之前完成此操作，而不是等到第一个用户反馈登录链接打开的是旧网站之后。边缘函数不会自动迁移。它们会继续在后端运行的地方运行，Coolify 上的前端会调用它们，这在迁移后端之前没问题，但如果你迁移了后端却忘了它们，就会出问题。

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.

Lovable 的预览功能依然有效，因为它从一开始就不需要你的服务器。这很方便：你可以继续在 Lovable 中构建、推送，一分钟后 Coolify 就会发布更新。如果你更希望有人帮你妥善完成数据库迁移和设置，我们可以提供固定价格的服务：将你的 Lovable 应用部署到你自己的服务器上收费 500 美元，如果需要迁移 Cloud 数据则另计。或者你可以告诉我们关于你应用的情况。原文发布于 lovable2live.com。Aakash Verma，软件开发者及 Lovable 2 Live 创始人。