This site keeps proposing one structure for regional infrastructure: mutual aid. Several small institutions share one operations layer instead of each pretending it can afford its own. The community-networks procurement post applied it to WiFi management — a shared OpenWISP instance, shared monitoring, one support contract. The pattern has now been built a layer up the stack, at a scale worth studying closely.

It's called Kube3, and it spans three German federal states: Baden-Württemberg, Bavaria, and North Rhine-Westphalia. Eight universities are in — KIT, Heidelberg, and Tübingen; the Leibniz Computing Centre and Bamberg; RWTH Aachen, Münster, and Cologne. The model: run Kubernetes-as-a-Service at several university sites, and let other universities and state agencies consume it under a business-to-business arrangement. Lena Becker (RWTH Aachen) and Martin Mai (University of Bamberg) presented it at the SCS Summit in May; the SCS community's write-up is the best public account. It is worth your time, because almost everything in it is replicable outside a university.

The structural problem it attacks

Kubernetes is the right tool for plenty of what institutions run: scalable research workloads, multi-tenancy, modern CI. Operating it, though, requires real expertise across networking, storage, Linux, IAM, backup, and certificate management. A large data centre has that staff. A university IT shop with two or three operators and a user base too small to justify the business case does not. The summit framing was blunt: many universities are "Kubernetes-free zones" — not for lack of knowledge, but because the cost-benefit analysis doesn't close if each one has to do it alone.

Anyone who has stood up infrastructure for a small institution has watched this decision get made. The capability isn't exotic. The math is the problem: N institutions each carrying a full-stack operator salary, against what any single institution actually needs.

The design decision worth copying: heterogeneous below, identical above

Each participating site operates its own virtualization layer — OpenStack here, KubeVirt there, Cozystack elsewhere. That heterogeneity is deliberate, not indecision. University data centres already have established infrastructure, and forcing migrations costs more than standardization returns. What Kube3 standardizes is one level up, at the KaaS layer — the part users actually touch.

The mechanics: each service gets a dedicated Kubernetes cluster, fully isolated, with its own virtual network. Monitoring, logging, support, and documentation are standardized across all of them. From the user's side, the platform feels the same whether the cluster happens to live in Munich or Aachen.

That boundary — don't fight the estate you inherited, standardize the interface above it — is directly transplantable to any regional mutual-aid project. The WiFi procurement argument drew the same line: standardize the management plane, leave room for heterogeneous hardware beneath.

What's running on it

The first workloads are unglamorous and exactly right: GitLab Runners that don't need a fixed location; Folio, the open-source library system, which several states intend to operate jointly; AI workloads; a persistent, portable project cloud for research consortia. No moonshots. Shared infrastructure earning its keep on boring, real demand.

The settlement trick

The long-term vision, half-joked Martin Mai: you click a service at your university, it starts wherever capacity exists — maybe Munich. You wouldn't notice. And settlement between the states is in compute-time credits, not money, to sidestep tax complications. That last detail is easy to skim past and shouldn't be. It's a federation where members trade capacity instead of invoicing each other — the same instinct that keeps a community mesh network off the billing-hamster-wheel.

The GDPR elephant

The most valuable part of the talk was the candid part. Microsoft Copilot is usable at these universities because a state-level framework agreement already settled the data protection questions at a level above the institutions. Sharing data with the neighbouring university — strictly lower risk in every real sense — requires case-by-case assessments, forms, and jurisdictional ping-pong, because no such agreement exists.

What determines whether cooperation happens is not the actual risk. It is whether responsibility has been pre-regulated above the individual institution. A network formally recognized by the participating states, like Kube3, buys exactly that: universities working together without every data protection officer reinventing the wheel.

For anyone building regional shared infrastructure, this is the lesson that never appears in the stack diagram: get the legal vehicle recognized at a level above your members, or the paperwork will eat the project. The technology is never what kills these efforts first.

The open question: flavours

One real failure mode has already surfaced. A setup that worked in Munich failed in Erlangen — not because something broke, but because the two deployments made different component choices. Kubernetes is a standard building block, not a standard; conformance of the whole depends on choices upstream never pins. Kube3 is exploring whether the SCS model of standardised, testable flavour definitions — already proven for virtual machines — should extend to Kubernetes: binding conformance profiles so a cluster in Munich and one in Aachen demonstrably deliver the same results. The SCS community has asked for feedback. This is the unresolved question for every region sharing a Kubernetes layer, and it is better answered by conformance tests than by trust.

Why this matters for community infrastructure

The ground under this is real and certified. Sovereign Cloud Stack's standards became mandatory in the German federal-state stack in March 2026. DATEV — Germany's largest IT service provider for tax consultants, auditors, and lawyers — has run an SCS-compliant IaaS platform in production since 2025. Certified KaaS operators exist. The building blocks for a regional shared-Kubernetes platform are documented, certified, and in production: a site to run the virtualization layer (SCS if you're ambitious, plain Proxmox plus Cluster API if you're normal), a standardized KaaS layer on top, shared monitoring and support, and the inter-organizational agreement.

And the honest ladder still applies. A fire hall should not run Kubernetes. It should run a homeserver that fits in 256 MB and Nextcloud on a Proxmox box, and stop. But a school district, a university, a hospital, a regional government association — those need a container platform, and individually none of them can afford to operate one well. That is the tier Kube3 is building: volunteer-run mesh at the bottom, shared regional platforms in the middle, hyperscalers unnecessary at every level.

The one-line summary of why it's copyable: nobody has to run everything alone, and nobody has to give anything up. Heterogeneity below, conformance above, and one signed agreement between institutions that decided the status quo — each of them alone with an impossible cost-benefit sheet — was the only thing actually broken.

The software has been ready for years. Kube3 is evidence that the agreement is buildable too.