There is no open source MLOps platform in the sense that there is a managed one. Nobody ships a single project that covers training, features, registry, serving and monitoring behind one install. What exists is a set of mature single-purpose projects that compose well, plus two or three umbrella distributions that bundle a subset and call it a platform.
That distinction is the whole decision. Choosing open source here is not choosing a product, it is choosing to own the integration and the on-call rotation in exchange for no licence fee and no data-plane lock-in. Teams that price only the first half of that trade end up with a stack nobody maintains.
Which project covers which layer
| Layer | Common open-source options | Operational weight |
|---|---|---|
| Feature management | Feast, Hopsworks (community edition) | Medium; needs an online store you already run |
| Experiment tracking | MLflow, Aim | Low; single server plus object storage |
| Orchestration | Kubeflow Pipelines, Flyte, Metaflow, Airflow, Prefect, ZenML | High; this is the cluster commitment |
| Data and artifact versioning | DVC, Delta Lake, Apache Iceberg, LakeFS | Medium; storage discipline more than services |
| Model registry | MLflow Model Registry | Low, if promotion discipline is enforced elsewhere |
| Serving | KServe, BentoML, Ray Serve, vLLM, Triton | High; autoscaling and GPU scheduling live here |
| Monitoring and evaluation | Evidently, Prometheus plus Grafana, NannyML | Medium; the alert route matters more than the library |
The table has a shape worth noticing. Two layers are nearly free to adopt and two are where the real cost sits. Tracking and registry are a single server against object storage. Orchestration and serving are distributed systems with GPU scheduling, and they are what turns “we run open source MLOps” into a platform team.
The three assembly patterns
Most working open-source stacks land in one of three shapes, and the right one follows from how much Kubernetes you already operate.
The lightweight stack. MLflow for tracking and registry, DVC or a table format for data versioning, a scheduler you already run for orchestration, and a container-per-model serving approach behind whatever ingress the company uses. This is the correct answer for teams under roughly ten engineers with a handful of models. It covers the seven functional layers described in MLOps platform explained without adding a cluster to maintain.
The Kubernetes-native stack. Kubeflow Pipelines or Flyte for orchestration, KServe for serving, Feast against Redis or a similar online store, MLflow retained purely as tracking and registry. This is the shape that scales, and it presumes a platform team that is comfortable debugging custom resources and admission webhooks. Kubeflow’s own architecture documentation is honest about this: it is a set of components on Kubernetes, not an appliance.
The framework-led stack. Metaflow or ZenML as the entry point, with the individual layers pluggable behind their abstractions. The pitch is that you write pipeline code once and swap the backing infrastructure later. It genuinely reduces the ergonomics gap for data scientists, and the cost is one more abstraction between your code and the thing that actually failed at 3am.
The trade-offs between the orchestration options are the highest-consequence part of this decision and are covered in detail in pipeline orchestration: Kubeflow vs Metaflow vs Flyte.
Where the open-source path is genuinely stronger
Three areas where the assembled stack beats a managed suite rather than merely matching it.
Portability of the artifacts that matter. Model files, feature definitions and pipeline definitions stay in formats you control. The registry contents move. That is the property that keeps a future migration a project rather than a rewrite, and it is exactly what a managed platform’s convenience features quietly erode. The failure modes are catalogued in model registry patterns that hold in production.
Serving efficiency at scale. Once GPU utilisation is the dominant cost line, control over batching, concurrency and model packing is worth more than a managed autoscaler’s defaults. Open runtimes expose the knobs directly. The levers themselves are the same ones described in inference cost optimization, but on managed serving several of them are simply not reachable.
No per-endpoint pricing distortion. Managed serving priced per endpoint pushes teams toward fewer, larger models for commercial rather than technical reasons. Self-hosted serving prices in hardware, so the architecture decision stays a technical one. The cost structure underneath is the same one covered in training infrastructure cost control: utilisation, not unit price, decides the bill.
Where it is genuinely weaker
Governance evidence. Managed platforms emit audit trails as a side effect of doing their job. Assembled stacks emit whatever you instrumented. Under model-risk regulation that difference is the deciding factor, not a preference, which is why the ranking inverts in best MLOps platform for regulated industries.
Feature freshness at low latency. Open feature stores handle the definition and point-in-time correctness problem well. The low-latency online path still depends on a store you operate and scale yourself, and that is where the effort concentrates. The comparison across options is in the feature store comparison.
Upgrade coordination. Seven projects on independent release cadences means compatibility is your problem. This is the cost that arrives in year two, not month two, and it is the most common reason an assembled stack quietly stops being upgraded.
Licence traps to check before committing
“Open source” is doing less work in this category than it used to. Three checks are worth running before a project enters the shortlist.
- Confirm the licence on the version you would actually deploy. Several projects in the ML serving and infrastructure space have moved newer major versions from a permissive licence to a Business Source License or a source-available licence while the older permissive version stays frozen. Read the LICENSE file on the branch you plan to run, not the project’s front page.
- Separate the open core from the paid control plane. Some feature stores and registries are permissively licensed for the engine while the management UI, access control or multi-tenancy sit in a commercial edition. That is a legitimate model, but it changes the comparison against a managed platform.
- Check who is actually merging. A project with one corporate sponsor and no external committers carries the same single-vendor risk as a commercial product, minus the support contract.
Cost is staff, not licences
The honest comparison against a managed platform is not licence fees against zero. It is a managed bill against cloud infrastructure plus the fraction of an engineering team that keeps the stack alive. Orchestration and serving are the two layers that consume that time, which is why the lightweight stack is the right call far more often than its reputation suggests: it defers both.
The rule that follows is about ownership rather than capability: if nobody can be named as the owner of cluster upgrades, the Kubernetes-native stack is not a viable option regardless of how well it scores on features. The inverse holds too. Where Kubernetes is already operated at scale, the incremental cost of the native stack is much lower than the managed quote suggests, because the expensive prerequisite is already paid for.
For a structured version of this comparison, the MLOps Platform Selector scores open-source and managed options on the same eight capability axes and lets you set an open-source-only hard constraint, so the shortlist reflects the licensing requirement rather than working around it. If the requirement is partial rather than total, the component-level view of replacing one managed vendor is in SageMaker alternatives compared, and the layer-by-layer scoring of the managed suites is in the enterprise MLOps platform comparison.
A note on model provenance
An assembled stack pulls models and images from public registries by default, and loading a model is executing code in more formats than teams assume. The mitigations are cheap when built into the pipeline from the start and expensive to retrofit: pinned digests, format restrictions, and scanning before a model reaches the registry. The attack paths are documented in ML model supply chain attacks and the deployment-side controls in secure ML model deployment best practices.
FAQ
Is Kubeflow a complete open source MLOps platform?
No, and its own documentation does not claim it is. Kubeflow is a collection of Kubernetes-native components covering orchestration, notebooks, training operators and serving integration. Tracking, registry, feature management and monitoring are typically supplied by other projects alongside it.
Can MLflow alone run a small production stack?
For tracking and registry, yes, and it is the most common foundation for the lightweight stack. It does not cover feature management, orchestration or monitoring, so the rest of the layers still need an answer even if that answer is a scheduled job and a dashboard.
How many engineers does a self-hosted stack need?
There is no universal number, but the useful test is ownership rather than headcount: name the person responsible for cluster upgrades, the person responsible for the online feature store’s latency, and the person on call when an endpoint saturates. If any of those three is unassigned, the stack is under-resourced.
Does open source avoid vendor lock-in entirely?
It avoids data-plane lock-in, which is the expensive kind. It does not avoid abstraction lock-in: pipeline code written against a specific framework’s decorators is as much a rewrite to leave as a managed platform’s SDK. Keep the model artifacts, feature definitions and registry contents portable, and accept that pipeline definitions will need rewriting either way.
Is a hybrid stack a reasonable end state?
It is the most common one. A managed platform for serving and governance with open-source tracking, versioning and orchestration underneath keeps the audit trail while preserving the portability of the artifacts. Treat the hybrid as a deliberate design rather than an unfinished migration.
