1 / 20
Multi-Tenant Edge Hosting

Turning an edge footprint into a
multi-tenant hosting platform

Multi-Tenant Operator — the layer that turns clusters
into something you can sell.

Multi-Tenant Operator OpenShift MicroShift

Stakater

Founded 2016

Ten years in business

Global team — 8 countries

Sweden, Czech Republic, Austria, Spain, Pakistan, Netherlands, Australia, Vietnam

Stakater Cloud

Runs in production on OpenShift

Red Hat Partnership

Premier Partner

Specialized Partner — Container Management

Master Services Agreement — the only one in Sweden, 5+ years

Partner since 2018

What We've Built

Cloud

Stakater Cloud

Our managed OpenShift cloud

Production workloads. Paying customers.

Open Source

Reloader

24B+ downloads · 9.9k stars

Forecastle

IngressMonitorController

+ many more

Red Hat Certified

Multi-Tenant Operator

Enterprise multi-tenancy for OpenShift

On the Red Hat Marketplace

Open source, commercial, and managed — running in production for years.

Introducing Multi-Tenant Operator

Tenant A
Tenant B
Tenant C
Tenant D
↕
Multi-Tenant Operator
Isolation · Access mapping · Quotas & policy · Extensions · Cost attribution · Hibernation
↕
OpenShift — datacenter
MicroShift — edge

A platform layer between the customers you sell to and the clusters you run.

Everything hosting has to solve

Tenancy
A customer is a real boundary, not a naming convention. Access, network and storage held apart — and kept that way.
Templates
The things you sell, defined once. A versioned catalogue of offerings instead of a bespoke deployment per customer.
FinOps
Who used what, per customer. Consumption broken out by tenant, with budgets and spend alerts.
Hibernation
Stop paying for idle. Non-production tenants sleep on a schedule and wake when someone needs them.
Compliance
Governance that holds between audits, not just during them — plus a record of who got what, and when.
Extensions
The surrounding tooling wired up per tenant — GitOps, secrets, identity, observability — rather than by hand, per customer.

Not a feature list — the areas you have to close before hosting is something you can sell. You'll see five of them running shortly.

Cost by construction

Every workload is born inside a boundary that is already metered.

Cost per customer

Not cost per cluster, divided up afterwards by hand.

One view, every footprint

Datacenter and edge under a single tenant model.

Nothing to reconcile

No month-end project to work out who consumed what.

Attribution is not a report you run against the platform. It is a property of how workloads are deployed.

What it changes for the business

Time to first revenue

Onboarding a customer is a job template run, not a project with a delivery engineer attached.

Margin you can see

Cost per customer per site, continuously — so pricing is a decision, not an estimate.

Density without risk

More tenants per cluster when isolation is enforced by the platform rather than by convention.

Audit that holds up

Every change ordered through one front door, every boundary reconciled and observable at any moment.

Multi-Tenant Operator enforces
what Ansible provisions.

The setup for everything that follows.

Ansible Automation Platform
Trigger → Converge → Run ends
Correct as of the run.
Multi-Tenant Operator
Watch → Diff → Act ↻
Correct continuously.

A natural split — Ansible Automation Platform as the orchestration layer, Multi-Tenant Operator enforcing the result continuously underneath it.

The reference stack

A baseline to point back at during the demo.

Ansible Automation Platform
Job templates and surveys · approvals · credentials · audit
↓
Hub cluster
Multi-Tenant Operator · Template Operator · Advanced Cluster Management
↓
MicroShift
MicroShift
MicroShift
MicroShift
…fleet

Ansible never talks to an edge site directly. It declares intent on the hub.

How tenants and workloads deploy

Onboarding — once per tenant
Ansible playbook
kubernetes.core
→
Tenant resource
Created on the hub
→
Multi-Tenant Operator reconciles
Namespaces · access mapping · network isolation · quotas — and keeps reconciling
Delivery — every workload after that
Ansible playbook
Parameters passed in
→
TemplateInstance
Workload resources — landed inside the tenant boundary
→
Projected to the edge
Advanced Cluster Management places it on the target MicroShift site
A workload can only be born inside a boundary that is already metered.

The template is the interface

Ansible playbooks & business logic
Ordering, scheduling decisions, approvals — imperative, run-triggered
Decides
↓
TemplateInstance
A persistent declared object — the contract between the two layers
The seam
↓
Template Operator · Multi-Tenant Operator · Cluster Management
Continuous reconcile, down to the hardware at the edge
Enforces
↺
Re-run the playbook with new options → same object, new desired state → the fleet converges. Resize, relocate, upgrade a quota — all one mechanism.
The playbook doesn't execute against hardware. It writes desired state.

What we'll show you

1Tenant onboarding
2Quotas & policies
3Workload isolation
4FinOps — cost per tenant
5Hibernation
Ansible Automation Platform
Demo 1 starts here
↓
Hub cluster
Demos 1 – 5 land here
↓
MicroShift
MicroShift
MicroShift

We'll come back to this picture between each one.

Live demo — 1 of 5

Tenant onboarding

One tenant resource, everything else follows Namespaces, access mapping and quota appear together — not as four separate steps.
Delete something and watch it come back This is the difference between a run that finished and a boundary that holds.
The tenant owner sees only their own world Access is derived from the tenant, not granted per namespace.
Running on the hub cluster
Live demo — 2 of 5

Quotas & policies

The quota belongs to the tenant, not the namespace A customer gets one allowance, however many namespaces they use.
Policy applies to namespaces that don't exist yet Anything created later inherits it automatically — no re-run required.
Changing a tier is a parameter change Not a migration, and not a hand-edit on a cluster.
Running on the hub cluster
Live demo — 3 of 5

Workload isolation

Cross-tenant traffic fails Not because someone remembered to write a network policy.
One tenant cannot see another exists Isolation covers visibility, not just reachability.
Isolation survives the thing that usually breaks it A new namespace, a new workload, a manual change during an incident.
Running on the hub cluster
Live demo — 4 of 5

FinOps — cost per tenant

Cost broken down by tenant, not by cluster The same shape as the invoice you would send.
An untagged workload has nowhere to land Deployed outside the platform, it can only show up as unattributed — someone works out who owed for it at month end.
Offerings arrive already attributed Cost tracking ships in the same bundle as the workload, so there is no tagging step to forget.
Running on the hub cluster
Live demo — 5 of 5

Hibernation

Sleep schedules per tenant Non-production tenants stop consuming outside working hours.
Resources released, configuration kept Waking up is not a redeploy.
Visible immediately in the cost view The saving lands in the same place the spend does.
Running on the hub cluster

Next session — the automation

A working session. We build it together, on your platform.

1
The order form
A job template with a survey — customer, tier, target site. The interface your service desk actually uses.
2
Onboard a tenant
The playbook creates the tenant on the hub. Isolation, access and quota come up under it.
3
Deploy a workload
A second template instantiates an offering — the workload placed inside a tenant boundary, on the site the survey chose.
By the end of that session you have an orderable service, not a demo environment.

Getting there incrementally

1
Hub first
A handful of tenants on the hub cluster. Isolation, quotas and cost attribution proven before anything ships to a site.
2
Out to the fleet
Offerings projected to edge sites. The same tenant model, the same cost view, now spanning both footprints.
3
Self-service
Customers order for themselves. Event-driven automation handles budget thresholds, quota breaches and day-two response.
No re-platforming between phases Each phase is independently useful

What you're selling
is the boundary.

Make it one that
never stops being true.

Proposed next step
Automation working session
Your Ansible Automation Platform, your cluster. We leave with a tenant and a workload deployed from a survey — an orderable service, not a demo environment.
Then — hub pilot Then — edge rollout plan