Platform Ops is a newsletter about running Kubernetes, OpenShift and the Linux underneath them in production — written from systems that broke, not from vendor documentation.
Platform Ops is written by one engineer, from production systems rather than from vendor documentation. Every issue starts with something that broke, something that was slower than it should have been, or something whose official explanation turned out to be incomplete.
The subject is the operational half of platform engineering: Kubernetes and OpenShift, the Linux underneath them, the networking and storage they depend on, and the observability that tells you which of those is lying to you. It assumes you already know what a Pod is. It does not assume the default settings are correct.
There is no sponsorship, no tracking beyond page counts, and nothing is behind a signup wall — every page is readable without an account. The archive stays up; issues are corrected in place rather than silently replaced.
685 topics, grouped into 45 categories under 13 pillars. The table is generated from the same file the site's knowledge map and every category page read, so these numbers cannot disagree with the ones you see elsewhere.
| Pillar | Categories | Live | Pipeline | Planned |
|---|---|---|---|---|
| Foundation | 1 | 7 | 0 | 3 |
| Roadmaps | 1 | 0 | 0 | 18 |
| Infrastructure | 3 | 1 | 8 | 29 |
| Networking | 1 | 1 | 4 | 26 |
| Cloud | 1 | 0 | 4 | 13 |
| Delivery | 6 | 12 | 22 | 42 |
| Kubernetes & OpenShift | 3 | 58 | 0 | 0 |
| Reliability | 7 | 27 | 25 | 64 |
| Security | 2 | 0 | 18 | 28 |
| Data & Applications | 4 | 1 | 12 | 47 |
| System Design | 1 | 0 | 0 | 46 |
| Commands | 10 | 44 | 34 | 22 |
| Modern Ops | 5 | 3 | 21 | 45 |
| Total | 45 | 154 | 148 | 383 |
Live means a published page covers it and the topic links straight there. Pipeline means it sits next to a series already running, so it is queued rather than hypothetical. Planned means it is on the backlog with no date attached — it moves up when the series in front of it lands.
Publishing the planned list is deliberate. A coverage map that only shows what is finished tells you nothing about what the project is actually trying to be.
Depending on whether you came here to read something, to look something up, or to find out whether a subject is covered at all.
| Start here | If you want |
|---|---|
| Issue #067 — Service Mesh Operations | The newest issue. There are 21 in the archive, all linked from the homepage. |
| Category hubs | To browse by subject. Each of the 45 categories has its own page with a generated architecture diagram and its full topic list. |
| The Kubernetes & OpenShift topic map | To check whether something specific is covered, queued or planned before you spend time looking. |
| Command references | To look something up fast. 4 references covering 362 commands, searchable and filterable by group. |
There is also a practice terminal — a Unix shell simulated over an in-memory filesystem, so you can try the commands without a cluster and without consequences.
Every page here is static HTML generated by a Python build from a single taxonomy file. No framework, no client-side rendering, no build-time JavaScript.
That choice is not nostalgia. It means the counts on the homepage, in the category hubs, in the topic map and on this page are all computed from one file at build time — so they cannot drift apart, and a stage that would make them disagree fails the build instead of shipping. Pages load without waiting for a bundle, and they keep working with JavaScript off.
The colophon has the full account: the build stages in order, what each one reads and writes, and the checks that gate a deploy.
A platform engineer who spends his working days on the systems this newsletter is about.
The writing is first-hand. Where an issue describes a failure, it is a failure that happened; where it gives a number, the number was measured rather than quoted. When something here turns out to be wrong, the page is corrected and the correction is visible.
Platform Ops is published by Srivan Technologies. You can reach the author through the author section on the homepage.
Two licences, because the code and the writing are different things.
| What | Licence | In practice |
|---|---|---|
| The build system and code samples | MIT | Use them, change them, ship them commercially. Attribution appreciated, not required. |
| The writing and the diagrams | CC BY-NC-ND 4.0 | Quote it with credit and a link. Don't republish it wholesale, don't sell it, and don't publish an edited version as though it were the original. |
If you want to do something the second licence doesn't allow — translate an issue, use a diagram in training material, reprint a piece internally — ask. The answer is usually yes.
Several issues here describe failure modes where a confident but wrong answer costs real downtime. If you are feeding this site to a model and publishing what comes out, link the source page so a reader can check it against the original.