Build or Buy the LLM Control Plane?

The inference runtime is a solved, free problem: open-source engines run open-weight models on your own hardware at production quality today. The actual build-or-buy decision is the control plane, meaning identity, audit, retention, tenancy and incident response, and that work exists whether you write it yourself or license it.

This post is the framework we use in those conversations, including the parts that argue against buying from us.

The runtime is a solved problem

Five years ago, running a capable language model on your own hardware was a research project. Today it is a download. Engines like vLLM and Ollama serve open-weight models with throughput that holds up in production, and our own inference path, the gateway, daemon, CLI, infoserver and shared database schema, is Apache 2.0 licensed. You can run it commercially without ever talking to us.

This is worth stating plainly because vendors in this market tend to blur it. If someone charges you for "sovereign inference" as such, ask what specifically you are paying for, because the inference itself has a market price of zero. What has a cost is everything around it.

What is an LLM control plane?

The control plane is every capability that turns a model server into infrastructure an organisation can actually operate. In practice that means at least: identity and access, so that every request is attributable to a person or service; audit logging and retention, so that you can reconstruct who asked what, when, with which model; tenancy, so that departments share hardware without sharing data; model governance, so that you control which weights run and when they change; and the operational layer of vulnerability management and incident response.

None of this is exotic. All of it is the same work your organisation already does for every other production system. The reason it dominates on-premise AI budgets is volume: an inference deployment touches identity, networking, storage and compliance at once, and each intersection needs a decision, an implementation and a test.

If you want the full breakdown of who is responsible for what, we are publishing the complete shared responsibility model for on-premise AI as its own reference page later this week.

What CVE-2025-47277 teaches about the boundary

In May 2025, a critical vulnerability was disclosed in vLLM. In affected versions, a component used for KV cache transfer between distributed nodes deserialised untrusted input, and the underlying PyTorch TCPStore interface listened on all network interfaces even when configured with a private address. The result was a remote code execution risk on multi-node deployments, patched in 0.8.5. The details are in the GitHub advisory.

Two things about this are instructive, and neither is "vLLM is insecure" .

First, the vLLM project is explicit in its security documentation that the engine is designed to run inside a secured, trusted network. That is scope honesty: the runtime declares which protections it provides and which ones it expects from its environment. The vulnerability was only reachable in deployments where that environmental expectation was not met.

Second, notice which side of the boundary the mitigation lived on. The patch was the project's job. Knowing the CVE existed, knowing whether your configuration was affected, isolating the interface until you could upgrade, and proving afterwards that you did: all of that was the deployer's job. That is the control plane, and no licence, open or commercial, does it for you.

This is why we phrase our own claim carefully. Buying a control plane does not make you compliant. It makes your compliance provable, because the logs, access records and model inventory an auditor asks for exist as a property of the system rather than as a document someone wrote afterwards. The obligations stay yours either way.

What do you get for free?

The honest answer, package by package:

The whole inference path is free and stays free. The dashboard is source available, which means the code that enforces your access control is readable even though it is not open source. The commercial line begins exactly where single-team deployments end: running many nodes and isolating many organisations on shared infrastructure.

We publish this table because it is the answer to the question every evaluation should start with, and because a vendor who will not produce the equivalent for their own product is telling you something.

When building is the right call

Building your own control plane is legitimate, and some teams should. The pattern we see succeed: a platform team that already operates internal developer infrastructure, an identity provider and logging pipeline the AI workload can inherit, one or two teams consuming inference rather than twenty, and no near-term audit that depends on the AI system specifically. In that situation, wiring a runtime into your existing SSO and shipping logs to the pipeline you already trust is weeks of work, and owning it outright is worth those weeks.

The pattern that fails is treating that estimate as the whole project. Identity integration is the first item, not the last. Per-key usage attribution, retention policies that legal signs off on, model change management and tenant isolation each take longer than the inference setup did, and they arrive after the demo worked, when the organisation believes the project is done.

When buying is the right call

Buying makes sense when the calendar, not the engineering, is the constraint. If departments are already pasting sensitive data into public chatbots, every month without a governed internal alternative is accumulating risk. If an EU AI Act use case classification or a sector audit is on the calendar, the evidence layer needs to exist before the auditor arrives, not after. And if the team that would build the control plane is the same team keeping the rest of production alive, the build estimate should include what that team stops doing meanwhile.

The test we suggest is narrow: get any runtime serving a model this week, ours or another, and then attempt one end-to-end control plane task, for example producing a per-user log of every request from the past 24 hours, attributable through your real identity provider. If that takes an afternoon, you have the platform maturity to build. If it opens a project plan, the plan is what you are deciding to build or buy.

The decision framework

Four questions settle most cases. Who consumes inference, one team or many, because tenancy is where build costs compound. What has to be provable, and to whom, because audit evidence designed in retrospect is expensive and unconvincing. Who patches, watches and responds at 2 a.m., because CVE-2025-47277 will not be the last advisory in this stack. And what does the building team not do instead, because the real price of building is denominated in postponed roadmap, not salaries.

If those answers point at building, build, and use our Apache 2.0 runtime as the base if it helps; that is what the licence is for. If they point at buying, the table above is exactly what you would be paying for, and the shared responsibility model, coming later this week, shows precisely where our obligations end and yours continue.

Frequently asked questions

Is the Xinity runtime really free for commercial use? Yes. The gateway, daemon, CLI, infoserver and database schema are Apache 2.0 licensed. You can run, modify and deploy them commercially with no agreement with us.

Does buying a control plane make us GDPR or EU AI Act compliant? No. Compliance obligations always remain with the deploying organisation. A control plane makes compliance provable by producing the audit logs, access records and model inventory that evidence your controls. The legal duties are yours; the system generates the proof.

What is the difference between the control plane and the inference runtime? The runtime loads models and serves requests. The control plane is everything that makes that operable in an organisation: identity, audit logging, retention, tenancy, model governance, vulnerability management and incident response.

Can we start with the open-source runtime and add the commercial layer later? Yes, and this is the path we recommend for evaluations. The open-source stack and the commercial features share the same architecture, so a single-node deployment carries forward unchanged.

Transparency note: This article was drafted with AI assistance and was reviewed, fact-checked and edited by the Xinity team, which takes editorial responsibility for its content. All sources are linked in the text.