What's your stack?
The platform uses a standard industry stack of K3s, Helm, Docker, and Postgres. Every app is deployed as a Helm release into a Kubernetes cluster owned by the user, not a proprietary sandbox.
Last updated
The platform uses a standard industry stack of K3s, Helm, Docker, and Postgres. Every app is deployed as a Helm release into a Kubernetes cluster owned by the user, not a proprietary sandbox.
Where does the app actually run?
Every application is deployed onto a K3s cluster in a namespace that belongs to your account. It is not hosted in a shared platform sandbox. The source is a real repository of Docker-compatible code, meaning you can run the application anywhere Docker runs.
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 "bring your own node" path allows the running cost of an app to approach zero.
How are apps deployed and updated?
When you push to the repository, the pipeline compares paths against the previous commit to identify which services changed. Only the modified images are rebuilt, pushed, and rolled out using helm upgrade --atomic. This ensures a zero-downtime rolling update on K3s.
If a release fails its health checks, the system rolls it back rather than leaving the app in a half-landed state. This is the same machinery used in professional DevOps environments, but driven by AI agents.
What tools run alongside the app?
Several cluster tools can be installed into your cluster in one click. These include MinIO for object storage, Velero for backups, and Falco for runtime security monitoring.
The agents use Ghost Browser, a real Chromium instance running in the cluster, to handle tasks that require a logged-in session. This allows the AI to read dashboards, fill real forms, or extract images from a chat to verify the app is working.
What happens when the stack fails?
Because the platform uses real infrastructure, it encounters real infrastructure failures. For example, a major Postgres bump from version 15 to 16 once caused a database to crash-loop because Postgres does not upgrade its data directory across major versions on start. The fix was to pin the database to its major version and treat upgrades as deliberate migrations.
Another failure occurred when Longhorn storage replicas were configured on a single node, which starved etcd of resources and crashed the control plane. The lesson was a hard rule: on a single node, only one replica is allowed, as redundancy on the same disk is load, not redundancy.
If you are currently using a hosted builder and want to move toward this model, you can read about what happens after my lovable plan or how to connect your own supabase project instead of lovable cloud.
my-app.engineer lets you describe an app in chat and then deploys it into a K3s cluster that you own, ensuring you have a path to owning your infrastructure without lock-in.