There is a certain kind of confidence that comes from building with AI right now. You prompt, it generates, and suddenly you have something that works. A service spins up. An API responds. A Docker container runs on the first try. It feels fast. Surprisingly smooth. Before long, it feels easy.
So it’s easy to assume… if you can vibe-code an app, why not vibe-code a self-hosted deployment too?
It seems straightforward. Ask for a Helm chart. Generate some Kubernetes manifests. Wrap it in a few instructions and call it self-hosted. For a demo, this works. For a quick internal tool, it might even hold up.
But building self-hosted software is less like prototyping an app and more like constructing a skyscraper. Yes, AI can generate something that looks like a complete set of plans. It can outline the structure, suggest the components, and give you something that appears sound. But no one would take those plans and immediately start construction. The margin for error is too small, and the consequences are too high. Between a plausible design and a building that is safe, stable, and long-lasting, there is a huge amount of validation, constraint handling, and engineering rigor.
Self-hosted software is not just about getting something to run once on your machine. It’s about getting that same software to stand up reliably across many different environments, each with their own constraints, configurations, and edge cases. An application can be written well and still fail in deployment. At that point, you are solving a different, and harder, problem entirely.
The illusion of the happy path
Most AI-generated deployments look good because they live on the happy path. They assume a clean cluster, modern Kubernetes versions, open networking, and full permissions.
The hard part is everything that happens after. Your customers are not running clean environments. They have constraints you can’t see from your laptop. Some are air-gapped. Some have strict RBAC policies. Some are running older versions of Kubernetes that can’t be upgraded easily. Others have networking rules that break assumptions you did not know you were making.
A generated Helm chart can get something running. It can’t tell you whether that deployment will survive its first upgrade, or its tenth. It can’t reason about how state changes over time, or how to recover when something fails halfway through. It’s the difference between a building that looks complete from the outside and one that can actually withstand years of stress, change, and real-world conditions.
This is where the gap starts to show. A deployment that works once is not the same as a deployment that works reliably across many environments.
What you’re actually signing up for
Shipping self-hosted software means you’re no longer just building an application. You’re building a system that has to operate inside infrastructure you don’t control. In other words, you’re not just designing the skyscraper, you’re responsible for making sure it stands on every kind of foundation your customers might have.
That system has to be installable in restricted environments. It has to move artifacts into places that may not have internet access. It has to handle versioning, upgrades, and rollbacks in a way that doesn’t break customer data. It has to expose enough visibility that you can debug issues without direct access.
None of this shows up in a generated YAML file.
Distribution alone becomes a problem. How does your software get from your build pipeline into a customer’s cluster? What happens when that customer can’t pull from public registries? How do they mirror images, manage dependencies, and verify what they’re installing?
Then there’s day two. The first install might succeed, but what happens when an upgrade fails halfway through? What happens when a dependency changes in a way that breaks compatibility? What happens when two environments that look similar behave completely differently?
AI can help you sketch the blueprint. It can’t take responsibility for whether the building holds up once people move in.
Where things break down
The most common failure mode is not that the deployment doesn’t work. It’s that it doesn’t age well. A chart generated today might install cleanly. Six months later, after a few iterations, small decisions start to compound. A change that seemed harmless introduces a breaking upgrade. A missing migration path corrupts state. A configuration that was too permissive becomes a security risk.
These are not problems you can solve with better prompts. They require an understanding of how systems evolve over time, how changes propagate, and how to maintain structural integrity as complexity increases.
This is where support becomes real. When a customer runs into an issue, you need a way to understand what is happening in their environment. You need diagnostics, reproducibility, and a path to resolution that does not depend on guesswork. It’s the equivalent of inspecting a building you didn’t construct, without being able to see inside the walls.
Self-hosted software is not just about shipping something that runs. It is about supporting something you can’t see.
Why this exists as a category
This is the reason companies end up rebuilding the same set of tooling again and again. They start with a working deployment, then slowly add the pieces they need to make it viable in production.
Installers. Upgrade logic. Packaging and distribution. Support workflows.
It is rarely planned this way. It emerges as a response to real customer friction, the same way real-world construction adds layers of safety, validation, and process over time.
AI does not change that dynamic. It can accelerate the early steps, but it does not remove the need for the underlying system.
This is also where platforms like Replicated come in. Not as a shortcut, but as an acknowledgment that this problem space is deeper than it looks. Distribution, upgrades, and support are not edge concerns. They are the core of making self-hosted software work, the equivalent of everything that happens between a blueprint and a building that people can trust.
You can absolutely vibe-code parts of your product. You can move faster, generate scaffolding, and reduce the time it takes to get to a first version.
But there is a difference between getting something to run and making it reliable across real customer environments.
You can vibe-code a demo. Reliability still has to be engineered.