Changing a platform without stopping it: a decade of Zalando's cluster fleet
How one European retailer has kept a fleet of production Kubernetes clusters current between 2015 and 2026, reconstructed from the public repository its platform is changed through.
Zalando's production cluster configuration has been a public repository since 2017, and it took a change on the day this guide was written. The guide reads a decade out of it: the branch-per-risk-appetite promotion model and its human gate, the sixty-three component inventory split into mechanism and policy, the two postmortems the company published in 2019, and the in-place move onto managed control planes that is visible in configuration but announced nowhere. A reader can take the build-versus-rent test, the promotion model with its measured four-day merge-to-production path, and the archaeology method that produced all of it without reading a single blog post.
The decision records argue for three channels and the running pipeline has four, promoted through two standing pull requests that nobody wrote down; and the postmortem directory received four commits in 2019 and none since, while the configuration beside it is still changing daily.
What you get out of it
- Fleet upgrades are restartable because the reconciler holds no state: three version strings live in a registry it does not own, and rollback is a string rather than a procedure.
- The in-house components that survived nine years are the ones encoding company policy (ingress mapping, pod identity, downscaling, disruption floors); the ones replaced by upstream were all mechanism.
- Both published outages are the same failure: a component everything depends on, sized from average usage. Only one fix changed the architecture, by making the resolver per-node instead of cluster-wide.
- A change reached production in four days through the channels, measured from the merge of the June 2019 kubelet fix to its arrival on the stable branch.
- Where a decision record and a pipeline definition disagree, the pipeline is the architecture: read them together or you will document a fleet that does not exist.
Scope
Why this, now. Platform teams are being asked in 2026 whether nine years of in-house Kubernetes tooling should now be handed back to managed services, and this is the only fleet whose answer is legible commit by commit.
What it does not cover. No engineering blogs, talks, papers, peer comparison or cost analysis: the session's network policy reached code hosts only, so every figure here is self-reported by the company that runs the system, and nothing covers Zalando's application or data architecture.
Other field guides
The half-life of in-house infrastructure: a decade of Uber, read from its own repositories
A decade of one company's platform decisions read from the artefacts nobody edits on purpose: archive banners, last-commit dates, closed-unmerged pul…
26 sources · 8 organisations · 4 postmortemsThe monolith that could not be split: ten years of GitLab architecture, 2016-2026
A decade of one company's architecture, reconstructed entirely from primary artefacts: design documents with status fields, twenty-eight numbered dec…
32 sources · 2 organisations · 7 postmortemsWhen name resolution fails, the record was wrong, not the server
Six published incidents (AWS October 2025, Meta 2021, Slack 2021, Cloudflare 2025, Salesforce 2021, Roblox 2021) plus the build records at Stripe, Ku…
28 sources · 26 organisations · 6 postmortems