What happens after you take a Lovable app to production?
You hit a deployment wall where you no longer own your infrastructure and face unpredictable credit billing. To truly move to production, you must migrate from a hosted sandbox to a environment where you own the cluster and the source code.
Last updated
You hit a deployment wall where you no longer own your infrastructure and face unpredictable credit billing. To truly move to production, you must migrate from a hosted sandbox to an environment where you own the cluster and the source code.
Why is there a deployment wall?
Most AI builders lock you into their proprietary cloud. They provide a convenient sandbox for the "vibe-coding" phase, but they do not give you a path to owning the underlying machinery. When you move to production, you find yourself paying for the builder, the hosting, and the database separately, often totaling $45 to $159 per month before you have a single customer.
The real problem is lock-in. If you want to leave a hosted builder, you cannot simply move the "app" because the app is a set of configurations inside their proprietary system. Leaving often means starting again or fighting with an export that does not run anywhere else. You are paying for the privilege of not owning your business's core asset.
How do I actually own my production infrastructure?
True production ownership means your application lands in a Kubernetes cluster that you own, not a sandbox owned by a platform. When the app is deployed as a Helm release on K3s, the source is a real repository. It is an application you could run anywhere Docker runs, meaning you can move it to any provider or your own hardware without asking permission.
To drive costs toward zero, you can join your own hardware to the cluster. A machine at home becomes a node in the cluster over a private network, and pods schedule onto it like any other node. This removes the monthly tax of hosted platforms and puts the hardware under your direct control.
What happens when production things go wrong?
Moving to your own infrastructure means you are responsible for the runtime. You will encounter real failures that hosted builders hide from you. For example, if you configure storage replicas on a single node, the replication traffic and disk contention can starve etcd until the control plane crash-loops and the cluster stops responding. The fix is a hard rule: on a single node, you use one replica.
Database migrations are another common point of failure. Moving an image tag from Postgres 15 to 16 will cause a database to crash-loop because Postgres does not upgrade its data directory across major versions on start. In a real production environment, a major upgrade is a deliberate migration process, never a simple tag change in a config file.
How do I avoid the "one-shot" fragility?
Many founders try to "one-shot" their entire app into existence, which leads to fragile code that breaks the moment you add a new feature. A stable path to production requires a blueprint phase. Before any code is written, you define a capability blueprint. This is a list of what the app must do, which you can edit or remove before the manager agent plans the build.
Once the blueprint is set, the build is verified by a QA agent that opens the deployed app in a real browser to check it against the blueprint. If the app does not do what the blueprint said, the build is not called done. This prevents the cycle of "fixing one bug and creating two more" that happens when you build without a verified spec.
If you are currently stuck in a hosted plan, you can read about /learn/what-happens-after-my-lovable-plan to understand the transition. For those who want to keep their current setup but stop the lock-in, /learn/how-to-connect-your-own-supabase-instead-of-lovable-cloud explains how to at least decouple the data layer.
my-app.engineer solves this by deploying your AI-built apps directly into a K3s cluster you own, providing the source code in a real repository and allowing you to add your own hardware as nodes.