Where can I host and make public my Vibe-coded app?
You can host your app on my-app.engineer, where it is deployed as a Helm release into a K3s Kubernetes cluster that you own. Your app becomes public at a unique address like <app>.<user>.my-app.engineer or via a custom domain.
Last updated
You can host your app on my-app.engineer, where it is deployed as a Helm release into a K3s Kubernetes cluster that you own. Your app becomes public at a unique address like <app>.<user>.my-app.engineer or via a custom domain.
Where does the app actually run?
The application runs on K3s in a namespace that belongs to your account. Unlike hosted builders that keep your code in a proprietary sandbox, this platform deploys your app as a real repository of source code. Because it uses standard Docker, Kubernetes, and Helm, the application is not locked into a specific platform.
You can reduce your running costs to near zero by using the "bring your own node" path. This allows you to join your own hardware to the cluster over a private network. A machine at home becomes a node in the cluster, and the system schedules your app's pods onto it just like any other node.
How do I make the app public?
Once the build is finished, the app is automatically assigned an address in the format <app>.<user>.my-app.engineer. If you want a professional presence, you can point a custom domain at this address. The routing layer handles the SSL certificate automatically so the site is secure.
The process of getting the app public follows a strict pipeline. The manager agent plans the build, the builder agent writes the source to a repository, and the system deploys it. A separate QA agent then opens the deployed app in a real Chromium browser to verify it works before the build is marked as done.
Which build type should I choose for hosting?
The hosting configuration depends on the build type you select before the first line of code is written. A demo build is for showing a concept. It uses memory-only storage and has no payment integration.
If you are launching a business, you choose product or delivery. A product build is a standalone business with a real database and automatically provisioned payments. A delivery build is designed for clients, where the database is real but payments are wired directly to the client's own account. You cannot upgrade a demo to a product in place because persistence and payments are integrated into the core architecture of the app.
What happens if the deployment fails?
Deployments are handled via helm upgrade --atomic. The system compares paths against the previous commit to determine which services changed, rebuilding only those images. This ensures zero-downtime rolling updates. If a new release fails its health checks, the system automatically rolls back to the previous version rather than leaving the app in a broken state.
Infrastructure failures are handled through direct configuration changes. For example, if you run a single-node cluster, you must set storage to one replica. Attempting to run multiple replicas on one node creates disk contention that can starve etcd and crash the control plane. Similarly, major database upgrades, such as moving from Postgres 15 to 16, are handled as deliberate migrations rather than simple image tag changes to avoid crash-looping the data directory.
Can I add other tools to my host?
You can install a catalogue of cluster tools directly into your K3s cluster without needing a separate login. This includes MinIO for object storage, Velero for backups, and Falco for runtime security monitoring.
One of the most useful tools is the Ghost Browser. This is a real Chromium instance that the AI agents drive to perform tasks that require a logged-in session, such as reading a dashboard or filling out forms.
If you are moving away from a locked-in environment, you might want to see /learn/what-happens-after-my-lovable-plan or learn /learn/how-to-connect-your-own-supabase-instead-of-lovable-cloud to understand the infrastructure gap.
my-app.engineer provides the agents to build the app and the K3s cluster to host it, ensuring the founder owns the infrastructure from the first deploy.