At Replicated, we recently launched our Deep Dive Series, a new initiative designed to go beyond surface-level technical overviews and foster real, nuanced conversations about complex decisions in modern software delivery. In our first session, we tackled a question that frequently arises among teams deploying Kubernetes-based applications:
Should you deploy into an existing customer-managed Kubernetes cluster, or use Replicated’s Embedded Cluster instead?
This isn’t just a technical detail—it’s a key architectural choice that can influence everything from customer onboarding and supportability to long-term maintenance and scalability. In the session, hosted by our Director of Solutions Engineering Chuck D’Antonio and joined by VP of Product Amber Alston and Staff Product Manager Alex Parker, we aimed to clarify the decision-making process and highlight important considerations.
A recording is below, as well as a short summary of the conversation.
The goal isn’t to prescribe a single answer, but to help teams ask the right questions. Should your product prefer an embedded Kubernetes experience out-of-the-box, or should it integrate into whatever infrastructure the customer already has?
This often depends on factors like:
It’s clear from the start of the session that there is no “best” answer—only the one that best fits a given context.
One of the recurring themes in conversations is a persistent misconception: that Embedded Cluster is not a “real” cluster. Alex Parker addressed this head-on.
“Some folks assume that Embedded Cluster can’t match the reliability or robustness of something like EKS or GKE,” he explained. “They see the value for POCs, but hesitate when it comes to production environments.”
The reality is quite the opposite. Replicated’s Embedded Cluster is built on K0s, a production-grade Kubernetes distribution maintained by Mirantis. It’s a statically compiled, dependency-free binary that simplifies deployment dramatically—no additional packages or preconfiguration required. And because it uses K0s’s Autopilot feature, Embedded Cluster can be upgraded programmatically, helping maintain security and performance with minimal intervention.
This design decision wasn’t made lightly. The Replicated product team carefully evaluated multiple distributions, including the popular K3s, before selecting K0s for its balance of flexibility, simplicity, and robust feature set.
While Embedded Cluster shines during proof-of-concept and initial trials—where speed and simplicity are paramount—they are equally capable of supporting long-term production use cases.
By bundling Kubernetes directly into the installation process, vendors can provide a "push-button" install experience that reduces friction for new users. There's no need for the customer to stand up and manage their own Kubernetes environment just to try out your software. This is particularly helpful in customer environments with limited cloud or Kubernetes expertise.
And unlike other POC tools or sandboxes, Replicated’s Embedded Cluster is production-capable, featuring:
In short, it makes a strong case not just for evaluation, but for default deployment in many customer environments.
That said, Embedded Cluster isn’t a silver bullet. For customers who already operate sophisticated Kubernetes environments—especially in industries like finance or healthcare, where compliance and control are critical—deploying into an existing cluster remains the preferred choice.
These customers often already have:
For them, Embedded Cluster might feel too opinionated or duplicative. In these cases, supporting existing clusters provides the flexibility they need to integrate seamlessly into their ecosystem.
Ultimately, the decision of Embedded vs. existing cluster should start with the customer's goals and constraints, not with a blanket preference. Some customers will want the speed and simplicity of a bundled deployment. Others will demand fine-grained control.
The beauty of Replicated’s approach is that we support both models—empowering software vendors to meet their customers where they are, not force them into a rigid deployment framework.
As Amber Alston noted, our team’s focus is on removing friction at every stage of the customer lifecycle, from first install to production rollout and beyond. And that means enabling thoughtful, flexible deployment options that fit the reality of modern enterprises.
This session was just the beginning. As part of our ongoing Deep Dive Series, we’ll continue to explore the nuanced decisions that shape software delivery in the enterprise.
Interested in learning more? Keep an eye on replicated.com/blogs or follow us on LinkedIn for updates on future sessions and in-depth articles.
And if you’re facing this very question with your own software—embedded or existing?—we’d love to hear how you’re approaching it.