Hey {{first name | there}}. A storage feature shipped in Kubernetes 1.36, and it quietly changes who owns your runtime. Most teams will adopt OCI images as volumes before they notice it moved a boundary they had stopped thinking about.
In today's Technical Notes:
The Kubernetes 1.36 feature that moves a boundary you stopped watching
Why teams are dropping a custom image per site for one shared runtime
The credential change that never made the security advisories
🧠TOGETHER WITH EVERYTHINGDEVOPS
The Engineer’s Roundtable
“What if my pull request gets rejected?"
This is one of the biggest reasons engineers avoid open source.
But rejection is not failure, it's part of the process.
The better question is: What are maintainers actually looking for?
In 2 days, we'll break down how contributions are reviewed, accepted, and improved.
🕐5 pm BST
📍 LinkedIn Live: Register here.
📰 TECHNICAL NOTES: When a storage feature is really an architecture change
Kubernetes 1.36 graduated OCI images as volumes to stable, which lets application assets be mounted from an image rather than baked into the runtime container. It reads as a storage feature, though the thing it moves is the boundary between a runtime and the content that runs on top of it.
Separating the runtime from what runs on it
What changes underneath is the line between runtime and application content, which no longer has to exist as a single packaged unit.
The runtime starts to behave as a stable execution layer, while application content becomes a portable artifact attached at deployment time.
What teams are already trying
Early patterns already reflect the shift, with teams distributing corporate CA certificate stores as OCI images, sharing code between services like php-fpm and a web server without merging them into one image, and replacing git-sync sidecars with versioned OCI artifacts mounted at runtime.
Static web hosting makes it concrete, since instead of building a custom Nginx image per site, teams standardise on a single upstream Nginx runtime and publish only the static assets as OCI images, turning deployment into composition rather than rebuild.
The decisions it pulls into the open
Operational responsibility moves with that structure, as runtime lifecycle and patching drift toward platform teams while application teams manage artifacts and release cadence on their own, replacing implicit coupling inside the container with explicit separation of concerns.
Once that boundary is removed, decisions that used to sit hidden become visible, including runtime ownership, patch cadence, version tracking across environments, and how security tooling observes components that no longer ship as one unit.
These are familiar problems that already exist in most systems, but separation changes their visibility and forces explicit ownership where it used to be assumed.
Platform design tends to evolve by making boundaries easier to see and manage on their own, and OCI volumes fit that pattern. The assumption that it quietly removes the requirement that a runtime and its content must ship as a single unit is the part worth watching.
If you're running OCI volumes in production, or holding off until runtime support settles, reply to this email and tell me where you've landed
🌍IN THE ECOSYSTEM
OCI Image Volume Security - A recent breakdown of the security surface the feature opens, including credential changes that shipped as quiet fixes. It matters the moment your content stops shipping as a single image.
KEP-4639: OCI volume source - The authoritative spec, including the read-only constraint, pull policies, and runtime support. Read it before building on the feature, since the caveats are here, not in the release notes.
ORAS - The de facto tool for pushing and pulling non-image artifacts to OCI registries. It's how your static assets, certs, or config become the artifacts this feature mounts.
💡PRESNTED BY EVERYTHINGDEVOPS
The Engineer’s Roundtable
“What if my pull request gets rejected?"
This is one of the biggest reasons engineers avoid open source.
But rejection is not failure, it's part of the process.
The better question is: What are maintainers actually looking for?
In 2 days, we'll break down how contributions are reviewed, accepted, and improved.
🕐5 pm BST
📍 LinkedIn Live: Register here.
⏱️UNTIL NEXT TIME
The boundary this feature moves was always there, just hidden inside the container where nobody had to name an owner for it.
Pick one image in your stack that bakes runtime and content together, and decide which team would own each half if you split them.
Know an engineer who'd want this? Share this link with them
Jubril Oyetunji
CTO, EverythingDevOps
