Edera 1.11: VM Workloads, Native Policy, 4x Faster Zones

Platform teams rarely stall on whether architecture works. They stall on the list of things they would have to change first. Containerize the legacy fleet. Rebuild the policy. Fork the Helm chart. Patch the application so its logs still show up. Every item on that list is a quarter the project slips.

Edera 1.11 is aimed at that list. VM-based workloads now run on Edera without being containerized first. Kubernetes security policy applies inside zones with no second configuration path. Off-the-shelf charts deploy unmodified. Edera’s zone (MicroVM boundary) startup is roughly 4xfaster, which changes the math on every workload you launch.

The full release notes have the complete change list. This post covers what the release changes about what you can run, and what it costs to run it.

VM Workloads Now Run on Edera Without Containerizing

Edera zones now boot full virtual machine images in raw disk, QCOW2, and AMI formats, as a new zone type running alongside container zones on the same nodes.

This matters because containerization has been an unstated prerequisite. Plenty of production workloads are not containerized and will not be soon: software distributed and licensed as AMIs, GPU fleets built around VM images, appliances and applications that live in VMs for reasons that are still good ones. Rewriting them is a multi-quarter project with its own risk, and it has to finish before the security work can start.

That sequencing is gone. VM workloads run in their existing form, with the same guarantees as your containers and one operational model across both. For teams whose infrastructure isn't fully containerized, which is most teams, this widens where Edera fits from a subset of the estate to the whole thing.

For GPU cloud providers specifically, it means the fleet you already sell can move onto Edera without repackaging what your customers deploy.

Native Kubernetes Policy Enforcement Inside Zones

The hidden cost of adding a runtime is usually the parallel configuration path. Every control the security team has built gets rebuilt, then maintained twice, and the two copies drift.

Edera now honors the seccomp and AppArmor profiles declared in your pod specifications, applying them inside the zone where the workload runs. Read-only volume mounts are enforced within the zone, so a mount declared read-only in Kubernetes behaves that way at the workload boundary. Your existing Pod Security Standards and hardening baselines carry straight over, and platform teams apply one policy across every runtime class in the cluster. Security teams get syscall-level restriction and mount enforcement operating inside a hardware-backed boundary, which is defense in depth without a second policy surface to audit.

Application compatibility improves on the same principle. Workloads running as non-root users now have full access to standard output and error streams inside zones, so common ingress controllers and public Helm charts deploy without modification and their logs land in your aggregation stack as expected. Fewer forked charts means fewer things your team owns forever.

Kernel selection follows suit. Specialized zone kernels are chosen by name, so selecting the nvidia variant resolves the right build automatically, and you can register your own kernels as named variants and select them the same way. Manifests reference a variant rather than a version, which means upgrades no longer touch your manifests. Bringing your own kernel becomes a supported path rather than a special case.

Zone Lifecycle Reporting Built for Fleet-Scale Kubernetes

The distance between a successful pilot and a production fleet is measured in how much your automation can be trusted to act alone.

Zones now report their state to Kubernetes throughout the lifecycle, including under memory pressure. Zone networking stays stable through cluster churn. We have substantially expanded test coverage of zone lifecycle and failure scenarios.

The practical effect is that controllers, autoscalers, and remediation workflows see what is actually happening and respond correctly without a person in the loop. That is the difference between a platform your team operates and a platform your team babysits, and it is what keeps headcount from scaling with node count.

4x Faster Zone Startup With Expanded NUMA Support

Zone startup is substantially faster, roughly a fourfold improvement on common configurations, alongside throughput gains in Edera's internal messaging layer.

Startup latency is paid on every single workload launch, so the improvement compounds across the fleet. CI and build fleets cycle through more jobs in the same window. Autoscaling responds to demand faster, which means less headroom provisioned to cover the lag. Burst-heavy workloads spend more of their time working and less of it starting.

The release also extends NUMA support. You can specify topology per workload through pod annotations and inspect where a zone's CPUs and memory are placed, which is what latency-sensitive and memory-intensive applications need on large multi-socket hardware.

Performance overhead is the standard objection to stronger workload separation. This release narrows the gap on the metric teams actually feel.

What It Adds Up To

The through line in 1.11 is that adopting Edera should not require you to change what you run, how you configure it, or how you operate it. VM images remove the containerization prerequisite. Native policy enforcement removes the parallel security configuration. Compatibility and kernel selection remove the forks. Reliable state reporting and faster startup make fleet-scale operation practical rather than aspirational.

Read the full release notes for the complete change list, or contact us for a walkthrough of VM image support. You can also try Edera in your own infrastructure today with EderaON. EderaON is our single-node access program, valid for 90 days, that lets you run our hardened runtime on your own infrastructure. Get started here. 

FAQ

What's new in Edera 1.11?

Edera 1.11 adds VM-based workloads without containerization, native enforcement of Kubernetes seccomp and AppArmor policies inside zones, reliable zone state reporting, roughly 4x faster zone startup, and expanded NUMA support for GPU and HPC workloads.

Can Edera run VM-based workloads without containerizing them first?

Yes. Edera 1.11 introduces a new zone type that boots full virtual machine images in raw disk, QCOW2, and AMI formats directly, running alongside container zones on the same nodes, so VM-based software does not need to be rewritten as containers.

Does Edera 1.11 enforce existing Kubernetes security policy inside zones?

Yes. Edera now honors seccomp and AppArmor profiles declared in pod specifications and enforces read-only volume mounts inside the zone, so existing Pod Security Standards and hardening baselines apply without a second configuration path to maintain.

How much faster is zone startup in Edera 1.11?

Zone startup is roughly four times faster in Edera 1.11, alongside throughput gains in Edera's internal messaging layer, which compounds across CI, autoscaling, and burst-heavy workloads that launch zones frequently.

‍