Edera 1.12: Workload Identity, Azure AKS & Bottlerocket

Edera 1.12 is out. The full release notes have the complete list; this is the shorter version of what changes for you.

If there's a theme to this release, it's that Edera is getting easier to not think about. We share your node's image cache instead of running a second one. We run on Azure AKS, which rounds out the three major managed Kubernetes services, and Bottlerocket support is now in Early Access. Isolation only matters if teams actually deploy it, and most of the work here went into removing the reasons they don't.

The rest of the release pushes in the other direction, deeper into the security model: cryptographic workload identity, a capability model that tightens privilege inside the platform itself, and meaningful progress on supply chain verifiability.

Half the Image Storage, Faster Workload tarts

Edera now shares your node's existing image blobstore instead of maintaining a cache of its own.

What this means for you: you stop paying twice to store the same image. Node storage for container images drops by roughly half, registry egress goes down because an image already on the node never gets pulled twice, and workloads start faster whenever the image is already local. If you run large images at scale, which describes just about every AI and data team, that shows up as real infrastructure cost and real startup latency.

Cryptographic Workload Identity with SPIFFE and SPIRE (Early Access)

Edera zones can now take part in SPIFFE/SPIRE workload identity. This release adds an Edera workload attestor plugin, secure projection of SPIRE-minted X.509 identities into attested zones, and per-workload control over agent socket access that is opt-in by default.

What this means for you: your workloads get verifiable, short-lived identity issued on the basis of attestation, and that attestation now includes the fact that the workload is running inside a hardware-isolated Edera zone. If you're building toward zero trust, this connects strong isolation to strong identity. Services authenticate based on what they probably are rather than on a secret someone handed them. Identity is granted per workload, so being in a zone doesn't confer blanket access.

This one ships as Early Access, which means we want you to try it and tell us what breaks, but it hasn't been through our full security review and isn't ready for production yet. Our release stages page spells out exactly what that commitment is. If workload identity matters to your architecture, this is the moment your feedback shapes it most.

An Object Capability Model for Least Privilege Inside Edera

We introduced an object capability model across Edera's internal services. Access to platform control operations is now granted as specific, narrow capabilities instead of broad permissions. Image fetch and pack operations run in isolated subprocesses that hold only what they need. Platform services talk to each other over capability-mediated channels. Our Helm chart also moved from a privileged daemonset to a privileged init container.

What this means for you: least privilege, applied to the isolation platform itself. Fewer components hold standing privilege, the ones that do hold narrow grants, and the persistent privileged footprint on your nodes is smaller. When your security team asks what Edera itself can reach on a node, the answer is tighter and easier to explain.

Edera Now Runs on Azure Kubernetes Service (AKS)

Edera installs and runs on Azure Kubernetes Service, including with Azure's default CNI and AKS-native kubelet configuration.

What this means for you: if you're standardized on Azure, you can adopt Edera on your managed Kubernetes service without custom node work. With EKS and GCE already supported, that's all three major managed platforms. One isolation strategy across your estate, whichever cloud a given team happens to be in.

Observable Memory Pressure and Exhaustion Metrics for Zones

Zones now report memory exhaustion explicitly. Guests signal pressure, the platform aggregates those events, and they show up as metrics you can alert on. Zones also behave much more predictably under memory pressure and kernel panic conditions, and memory reclamation is now coordinated with in-zone pressure signals.

What this means for you: memory exhaustion becomes something your monitoring catches and your automation handles, instead of something you piece together afterward. If you run dense multi-tenant nodes, you can alert on reclamation failure, set policy for how zones behave under pressure, and pack nodes more confidently because the failure mode is visible and defined.

200ms Faster Zone Startup and Denser Nodes

Zone startup on Xen is about 200 milliseconds faster thanks to a new low-level memory copy path, and concurrent zone teardown no longer contends. Zone forking, which is in Early Access, is now dramatically faster and produces zones that are immediately usable.

What this means for you: you pay startup and teardown costs on every single workload, so cutting them raises the ceiling on how fast a node can cycle through work. Forking takes that further for scale-out patterns. New zones come up from a warm template with shared memory rather than booting cold, which is the foundation for very high density per node. That matters most for short-lived bursty workloads like agent sandboxes and CI jobs.

Per-Workload Storage Configuration

Volume mounts and their filesystem backend can now be set per workload rather than per zone.

What this means for you: workloads sharing a zone can have genuinely different storage profiles. You can tune I/O for the one workload that needs it without imposing that configuration on everything next to it.

Supply Chain: Signed Artifacts, SBOMs, and Pinned Builds

Supply chain security is one of our larger investments right now, and a good chunk of it landed in 1.12. Every Edera-built component ships with an SBOM, and we improved the tooling and resiliency around generating and verifying them. Our OCI references are now pinned rather than floating, with the pinned reference acting as the single source of truth that drives our builds. Our Helm chart is published as a public package on GHCR, so you can pull and verify it like any other artifact. Zone kernel variant tags now refresh through an automated, auditable process.

We're not done. The broader effort ahead of us is an Edera-owned, repeatable AMI build with a committed lockfile, builds derived from the official cloud base images, SLSA provenance attestations, and digest-stable immutable release artifacts, all with a documented verification path.

What this means for you: if you have a software supply chain review standing between you and deploying Edera, this is the work that answers it. You can enumerate what's in our components, verify what you pulled is what we published, and pin to an exact artifact rather than a moving tag. We also want to be clear about the division of responsibility: for our machine images, the cloud provider owns the base distribution and its CVEs, and our layer is a thin, verifiable wrapper on top. That's a deliberate choice, because it keeps you on the provider's patch cadence for the operating system instead of ours.

Bottlerocket Support for EKS and Fargate (Early Access)

This is one a lot of you have asked for. Edera now runs on Bottlerocket, the immutable, container-focused Linux distribution AWS builds, and the standard node image behind EKS and Fargate. Our host-side stack ships as a Bottlerocket host container with access to the facilities it needs to run zones, and the infrastructure and image are available now for evaluation.

What this means for you: if you run EKS or Fargate on the default node image, adopting Edera has meant changing that image. This removes that tradeoff. Bottlerocket already separates customer workload containers from privileged host containers, and Edera's host-side stack drops cleanly into the latter, so this is a genuine architectural fit rather than something we bolted on.

Where it stands today: launching zones and workloads directly works, and we're actively hardening Kubernetes-driven pod creation. As with anything in Early Access, it's here for evaluation and feedback. If Bottlerocket is your standard, now is the point where telling us what you hit has the most influence on where this lands.

Get Started

• Full release notes for the complete change list.
• Contact us if you want to talk through workload identity or the containerd integration.

FAQ

What does Edera 1.12 change about image storage?

Edera 1.12 shares your node's existing image blobstore instead of keeping its own cache. Node storage for container images drops by roughly half, registry egress falls because an image already on the node isn't pulled twice, and workloads start faster whenever the image is already local.

How does Edera 1.12 support SPIFFE/SPIRE workload identity?

Edera zones can participate in SPIFFE/SPIRE through a new workload attestor plugin and secure projection of SPIRE-minted X.509 identities into attested zones. Attestation now includes the fact that a workload runs inside a hardware-isolated Edera zone, and agent socket access is per-workload and opt-in. It ships as Early Access.

Which managed Kubernetes services does Edera run on?

With Azure AKS added in 1.12, Edera now runs on all three major managed Kubernetes platforms alongside EKS and GCE. On AKS it installs with Azure's default CNI and AKS-native kubelet configuration, so teams standardized on Azure can adopt it without custom node work.

Is Edera on Bottlerocket ready for production?

Not yet. Bottlerocket support ships as Early Access in 1.12 for evaluation and feedback. Edera's host-side stack runs as a Bottlerocket host container; launching zones and workloads directly works today, while Kubernetes-driven pod creation is still being hardened.