Seldon Core 2: Kubernetes Model Serving With Kafka Pipelines and a Business Source License
An MLOps framework to package, deploy, monitor and manage thousands of production machine learning models
At a glance
- What is it?
- Seldon Core 2 packages models, pipelines and experiments as Kubernetes resources, routing data between components over Kafka. The architecture is opinionated, the licence is not OSI open source, and the README points elsewhere for almost every operational detail.
- Who is it for?
- Adopt Seldon Core 2 if you already run Kubernetes, need multi-model serving or overcommit on shared inference servers, and can accept a Kafka dependency and a Business Source License. Do not adopt it if you need an OSI-approved licence, if you want a single-process Python serving layer, or if you cannot operate Kafka.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 176 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Seldon Core 2 Is Actually For
The README describes Core 2 as an MLOps and LLMOps framework for deploying, managing and scaling AI systems in Kubernetes, from single models to modular, data-centric applications. That framing matters more than it looks. The unit of deployment is not a model file but a set of Kubernetes custom resources: servers, models, pipelines and experiments, each with its own user guide section in the docs. The problem being solved is the gap between a trained artifact and a running service that can be shared, versioned and routed to. Seldon's answer is to make that gap a Kubernetes API surface rather than a Python script.
The audience is infrastructure-adjacent. Someone who wants to serve a scikit-learn model from a laptop is not the target reader. Someone who has to run twenty models for four teams on one cluster, keep GPU costs down, and run an A/B test without a second deployment is. The feature list is written for that person: multi-model serving to consolidate models on shared inference servers, overcommit to deploy more models than available memory allows, autoscaling on native or custom logic, and experiments with A/B tests and shadow deployments.
The project is written primarily in Go and the default branch is v2, which matters because the repository carries two release lines at once. The most recent v2 release listed is v2.10.2 from December 2025, while v1.19.0 landed in January 2026. Anyone reading release dates alone could draw the wrong conclusion about which line is active.
Servers, Models, Pipelines: The Resource Model
The architecture visible in the README is compositional. A server is the inference runtime. A model is what gets loaded onto it. A pipeline joins models and custom components into an application. The docs split these into separate user guides, which tells you they are separate resource kinds with separate lifecycles, not fields on one object.
The transport between pipeline components is Kafka. The README says pipelines let you deploy composable AI applications leveraging Kafka for realtime data streaming between components. This is the single most consequential design decision in the project and it is stated in one bullet. It means a Seldon Core 2 pipeline is not a chain of in-process function calls. Each step publishes and consumes messages. That buys you asynchronous, streaming-shaped inference and decoupling between stages. It also means Kafka is not optional infrastructure for pipelines, and the operational surface of your inference stack now includes a message broker.
Custom components are the extension point. The README lists drift and outlier detection, LLMs and other custom logic as things you implement as plug-and-play components that integrate with the rest of the ecosystem. The mechanism is not spelled out in the README beyond that; the docs link to a components section is not among the listed documentation links, so the exact interface for writing one is something you would need to confirm from the docs site.
Overcommit is the other mechanism worth naming precisely. The README frames it as deploying more models than available memory allows, saving infrastructure costs for unused models. That is a scheduling trade-off, not a free win: models are loaded on demand and something has to be evicted when memory runs out. The README does not describe the eviction policy, and that omission is the kind of detail that decides whether overcommit is safe for your latency budget.
Getting It Running: Where the README Stops
The README does not contain installation commands. It links to an installation page under docs.seldon.ai/seldon-core-2/installation/installation and lists the doc sections for servers, models, pipelines, experiments and performance tuning. That is the honest state of the repository front page: it is a signpost, not a quickstart.
What you can confirm from the material is the shape of the work. You are installing into Kubernetes. You will define servers, then models, then pipelines as resources. You will need Kafka available for pipelines. Beyond that, the README gives no Helm chart name, no kubectl apply line, no namespace, and no config keys. I am not going to invent them. If you are evaluating this for adoption, the first hour of work is reading the installation page and checking it against your cluster version, not reading the README.
The release artifacts give one more concrete signal. There are two live lines: v2.10.2 and v1.19.0, with v1.19.0-rc.1 preceding the v1.19.0 release. A team starting today has to decide which line it is on before it writes any manifests, because the resource model described in the Core 2 docs is the v2 branch's model, and the default branch is v2.
The Licence Is Not Open Source in the OSI Sense
The repository metadata reports the licence as NOASSERTION, which is GitHub's way of saying it could not match the LICENSE file to a known SPDX identifier. The README resolves the ambiguity: Seldon is distributed under the terms of the Business Source License, with the complete version in the LICENSE file, and contributions are licensed under the same terms.
This is the fact that should drive the evaluation more than any feature bullet. The Business Source License is source-available. It is not the same as Apache 2.0 or MIT, and the practical restrictions depend on the parameters in the LICENSE file, which the README does not reproduce. I am not going to characterize those parameters because I have not read the file and the README does not state them. If your organization has a policy against non-OSI licences, or if you intend to offer the serving layer as part of a commercial product, the only correct next step is to read LICENSE in the repository and route it through whoever handles this at your company. The README also points commercial users to seldon.io, which suggests a commercial track exists alongside the source-available one.
There is a second-order cost here that is easy to miss. A licence that is not OSI-approved changes the calculus for contributors as well as users, since the README states contributions are licensed under the Business Source License. That affects whether outside engineers will send patches at all.
Where Core 2 Is the Wrong Tool
The clearest mismatch is scope. If you have one model and one endpoint, Core 2 asks you to run Kubernetes, install the control plane, and for pipelines stand up Kafka, in exchange for routing and autoscaling you may not need. A single-process model server behind a load balancer will be simpler to operate and simpler to debug, and the README offers nothing that changes that arithmetic at small scale.
The second mismatch is the Kafka dependency. The README presents Kafka as the mechanism for realtime data streaming between pipeline components. If your team has no Kafka operational experience, adopting Core 2 pipelines means adopting a distributed log as a side effect. That is a real cost, and the README does not offer a non-Kafka pipeline mode.
The third is documentation depth in the README itself. Feature claims are one line each. Overcommit says it saves costs for unused models but does not say what happens when a model that was evicted is requested again. Autoscaling says it works on native or custom logic but does not say which metrics are native. These are answerable questions, and the docs site is where the answers live, but a reader who evaluates from the repository front page alone will come away with a feature list and no failure modes. That asymmetry is worth naming: the README sells, the docs specify, and you should budget reading time accordingly.
The Alternative That Changes the Trade-off
The obvious comparison is KServe, which also runs on Kubernetes and also exposes model serving as custom resources. The difference in approach is the pipeline transport. KServe's model is request-response: an inference request arrives, is routed to a predictor, and a response comes back, with inference graphs expressed as a sequence of stages in that request path. Seldon Core 2's pipeline model is message-passing over Kafka, so components are decoupled producers and consumers rather than stages in a synchronous call chain.
That difference decides the fit. If your workload is a synchronous prediction API and you want the simplest possible path from model to endpoint, the request-response model is a shorter distance. If your workload is streaming, or you want components to scale independently and tolerate a slow stage without blocking the caller, Kafka between stages is doing real work for you. Seldon's own framing supports this reading: the README cites a position paper on desiderata for next-generation ML model serving as the influence behind these features, and the pipeline design is where that influence shows most clearly.
The second axis of comparison is licensing. KServe is an Apache 2.0 project under the KServe organization, which makes it the default choice for teams with a hard OSI-licence requirement. That is a policy difference, not a technical one, but it is often the deciding one.
Maintenance, Upgrades and the Two Release Lines
The repository is not archived and the last push is dated March 2026, so the project is active. What the release list shows is more interesting than that: v2.10.2 in December 2025, then v1.19.0-rc.1 in January 2026 and v1.19.0 later the same month. A v1 line still shipping releases after a v2 line has reached 2.10 means the project carries two supported surfaces, and the maintenance cost of that falls partly on users who have to pick one.
The default branch is v2, and the README's documentation links all point at the Core 2 docs. That is a strong signal about where new work goes, but it does not tell you the support horizon for v1, and the README does not state one. If you are running v1 today, the upgrade question is not just "how do I move to v2" but "how long does v1 keep getting fixes", and the repository material supplied here does not answer it.
On licence cost, the Business Source License means the maintenance picture includes a legal review, not only an upgrade cadence. The README states the terms are in the LICENSE file and that contributions carry the same terms. It does not state a change date or conversion terms, and I will not guess at them. Treat the LICENSE file as a required read before any upgrade planning, since a licence change between versions would be a bigger event than a minor version bump.
One practical note on scope: the README's feature list mixes Core 2 capabilities with references to a wider Seldon ecosystem of ML/AI products. When you plan a deployment, separate what the Core 2 docs cover (servers, models, pipelines, experiments, performance tuning) from what requires other Seldon products to be useful. The five documentation links are the boundary of what Core 2 alone gives you.
Editorial conclusion
Adopt Seldon Core 2 if you already run Kubernetes, need multi-model serving or overcommit on shared inference servers, and can accept a Kafka dependency and a Business Source License. Do not adopt it if you need an OSI-approved licence, if you want a single-process Python serving layer, or if you cannot operate Kafka. Before committing, read the LICENSE file in the repository rather than the README summary, confirm the Core 2 installation page matches your Kubernetes version, and check which of the two release lines (v2.10.2 or v1.19.0) your team will actually track.
Community notes