What happens after my lovable plan?
When a hosted AI app builder plan ends, you typically keep your source code but lose the hosting, the preview URLs, and any platform-managed infrastructure. The app stops running until you redeploy it somewhere else.
Last updated
What happens after your Lovable plan runs out or you cancel it is the same thing that happens with most hosted AI app builders: the code is yours, but the running app is not. You get a repository of source, React components, a Supabase schema, whatever the builder generated, and you take it with you. What you do not take with you is the platform's hosting, its preview environment, its automatic deploys, and any infrastructure it managed on your behalf. The app goes dark until you stand up your own hosting, wire up your own database, and deploy it yourself or find another platform to do it. That gap between "I have the code" and "the app is running again" is where most people get stuck, because the code was built inside assumptions the platform made about where it would run.
Do I keep the code if I leave?
Yes, in the sense that the source is exported as a standard repository. Typically a Vite or Next.js frontend with a Supabase backend, both of which are real technologies you can run elsewhere. The code is not locked behind a proprietary format. You can clone it, open it in VS Code, and run npm install locally. That part genuinely works and is one of the better things about Lovable compared to visual no-code platforms that export nothing usable.
What you do not keep is the runtime configuration that made it work on the platform. Environment variables, project-level Supabase settings, redirect URLs for auth, and any edge functions deployed through the platform's integration all need to be recreated manually in your new environment. The code tells you what it expects, but it does not hand you a docker-compose.yml or a Helm chart that reproduces what the platform was doing for you. You are reading the code and rebuilding the deployment story yourself.
Can I just deploy it somewhere else?
You can, but it is not a one-button operation. The frontend is the easy part. A static build that goes on Vercel, Netlify, Cloudflare Pages, or any static host. The backend is where the work is. If your app used Supabase, you either keep paying Supabase directly (migrating the project to your own Supabase account if it was managed through Lovable's integration) or you self-host Postgres and move the schema, roles, and storage buckets yourself. Auth, row-level security policies, and edge functions all come along as configuration you have to reapply.
This is the point where people discover that "no lock-in" has gradations. The source is portable. The deployment is not. A person who knows Kubernetes, Docker, and Postgres can have the app running again in a day or two. A person who does not is back to choosing between learning infrastructure or paying another managed platform to host it for them.
What if I want to own the infrastructure instead?
This is the question that leads people to look at self-hosted options. The appeal is that the running cost of an app approaches zero when you control the hardware, and the app does not go dark because a plan expired or a platform changed its pricing. The trade-off is that you are now responsible for the cluster, the database, the backups, and the security.
On this platform, the model is different from a hosted builder from the start. You describe an app in chat, AI agents build it, and it deploys as a Helm release onto a K3s Kubernetes cluster that belongs to your account, not a sandbox the platform controls. The app answers on <app>.<user>.my-app.engineer and you can point a custom domain at it. You can join your own hardware as a node over a private network using the bring-your-own-node path, which means a machine at home runs your pods and the running cost drops toward the electricity. The source is a real repository, not a proprietary export, and it is an application you could run anywhere Docker runs.
The build types matter here too. A demo build has no payments and memory only, meant for showing something works. A delivery build has a real database and payments wired to the client's account. A product build provisions payments automatically and treats the app as a business. A demo that later needs to take money is not upgraded in place. It is rebuilt as the type it should have been, because payments and persistence reach into every part of the app. That is a hard rule, not a setting, and it exists because pretending you can bolt payments onto a demo produces an app that is demo-shaped underneath.
What about keeping it running long-term?
A self-hosted cluster is only as good as its operational discipline, and the failures here are real. Longhorn was once configured with multiple replicas on a single node, and the replication traffic starved etcd until the control plane crash-looped and the cluster stopped responding. The fix is a rule: on a single node, one replica. Redundancy across replicas of the same disk is not redundancy, it is load. A major Postgres bump from 15 to 16 crash-looped a database because Postgres does not upgrade its data directory across a major version on start, so the container refused the existing data and restarted forever. The database is now pinned to its major version, and a major upgrade is a deliberate migration, never a tag change. These are the kinds of things that eat a self-hosted setup if nobody is watching, and they are why a platform that manages the cluster for you while keeping it yours has a reason to exist.
Backups run through Velero, runtime security through Falco, object storage through MinIO. All installed in the same cluster, reachable from the account without a second login. Deploys use helm upgrade --atomic, which means a release that fails its health checks rolls back rather than half-landing. QA is a separate agent that opens the deployed app in a real Chromium browser and checks it does what the blueprint said. A build that does not pass does not get called done. You can read more about how the build and deploy process works at /learn/ai-app-builder-self-hosted-kubernetes-tutorial and /learn/how-to-deploy-ai-agents-in-production.
my-app.engineer takes the position that the cluster should be yours from the first deploy, not something you migrate to after a hosted plan runs out. The app lands on your K3s cluster as a Helm release, the source is a repository you could run anywhere, and if you stop using this platform tomorrow the app keeps running because it was never in a sandbox here. The question of what happens after your plan is answered by the fact that there is no plan to expire. There is your cluster, your code, and your nodes.