For platform builders

Run many customers on one control plane

If you host applications for other people — as a hosting provider, an MSP, or an agency that keeps its clients' systems running — you need the thing Kubernetes namespaces are documented not to be: a tenant boundary you can put in a contract. This page is about what that boundary is made of here, and it cites the code for every claim, the same way the rest of this site does.

The build-versus-buy arithmetic, shown rather than asserted

Every platform company reaches the same fork: build the orchestration layer, or integrate one. We are not going to quote you an industry study we cannot show you. Here is the one figure that is ours, and where it comes from.

Our own pricing analysis puts a Kubernetes-focused DevOps engineer at $150,000 a year — that is the number we use internally when we compare our tiers against the alternative, and it is an estimate we made, not a salary survey we ran. The arithmetic from there is yours to do with your own numbers:

We publish no partner price on this page, and that is deliberate: we would rather tell you we have not set one than invent a number to fill the space. What a reselling arrangement costs depends on how many nodes you run and how you want to be billed, and that is a conversation.

Tenancy, primitive by primitive

Six things you would otherwise build. Each one is a link to where it lives in the source, so you can check rather than believe.

A tenant hierarchy, with sub-organisations

A tenant can have a parent. That is one field — ParentTenantID — and the whole hierarchy hangs off it: creating a sub-organisation under a parent, listing a parent's children, walking up the chain to find the root, and refusing an operation that would cross a branch it should not. If you resell to companies that themselves have departments, subsidiaries or client accounts, the shape already exists.

Consolidated or separate billing, per sub-organisation

Each sub-organisation is created either consolidated, where the parent is billed for it, or separate, where it is billed in its own right. It is a validated field on the tenant, not a convention in a spreadsheet, and consolidated is the default when the caller does not say. That is the difference between reselling under your own invoice and introducing customers who pay directly — and you can do both, in the same estate, at the same time.

Quotas that are enforced, not advertised

A tenant carries limits on how many deployments, how many containers, and how many replicas per deployment it may have. They are validated on the way in: a negative limit is a rejection, and a container ceiling below the deployment ceiling is a rejection too, because it describes an estate that cannot exist. A free tier you cannot enforce is a free tier that costs you money.

A Docker network per tenant

Tenant networks are named from the tenant's own identifier, and a tenant gets a default one whether or not it asks. Two customers on the same node do not share a network segment by accident, because there is no code path in which they share one at all.

Row-level security in the database, failing closed

Tenant separation in the audit store is enforced by Postgres itself, not by a WHERE clause somebody has to remember to write. The policy is fail-closed — a connection with no tenant set sees nothing rather than everything — and there is a dedicated test suite that exists to try to read across the boundary and fail to.

A WireGuard mesh per tenant, in three topologies

Each tenant's nodes are joined by their own encrypted mesh, configured as full mesh, partial, or hub-and-spoke. Hub-and-spoke requires you to name the hub — a hub-and-spoke mesh with no hub is refused rather than silently degraded to something else. For a provider with a central site and many customer edges, that third topology is the one that matters.

Why this is a boundary and a namespace is not

Kubernetes documents its own namespaces as not being a security boundary. That is not our characterisation of someone else's product; it is theirs, and it is the reason a platform built on namespaces ends up carrying a second isolation layer that somebody has to build and keep working.

Here the boundary is the tenant, and it is made of the six things above at once: separate networks, separate Vault paths, separate key-value space, database policies that fail closed, and a mesh per tenant. What we can offer as evidence is our own: nine dedicated isolation test suites whose purpose is to attempt cross-tenant access and be refused, and a security audit whose 184 findings and their remediation are published in full rather than summarised.

The proof, not the promise

Four pages on this site exist so that the claims above can be checked rather than taken:

• The audit record — hash-chained and on by default, with a standalone offline verifier you hand to an auditor. This is what you show a customer's compliance team when they ask what you can evidence.
• The security audit — 184 findings across six gated waves, with finding identifiers traceable to the comments that closed them.
• The multi-cloud proof — a live, guarded container migration between two independently-enrolled cloud nodes, re-verified against the control plane's own node registry.
• The reference deployment — 123 containers under one control plane on a single eight-core machine, including a 23-container regulated document-processing stack and an unrelated 36-container platform beside it.

Where your customers' data lives

Nodes belong to the tenant. Your customers' workloads, their volumes and their data sit on servers you or they control, in whatever jurisdiction those servers are in — the control plane holds orchestration state, not application data. For a provider selling into a market with residency requirements, that is the useful arrangement: the answer to “where is my data” is “where you put it,” and it does not depend on where we are.

Geographic placement enforcement — pinning a workload to a country or region within your own fleet — is available and off by default. We would rather say that than imply it is switched on.

Talk to us

If you are building a platform on top of this, the next step is a conversation about node counts, billing shape and what your customers will ask you to prove. Write to sales@delta-telematics.ca.