Edera 1.13: Single Helm Install, ARM64 Graviton, KVM & More

Edera 1.13 is finally here!! The full release notes have the complete list of changes. This is our second condensed version of what changes in the latest release

If there's a theme to this release, it's that Edera is becoming easier to run in the places you already run Kubernetes. We now finally have a single install/upgrade path, our support for AWS Bottlerocket is moving toward production, and now Edera runs on ARM64 with AWS Graviton. Memory accounting now speaks Kubernetes' language, closely integrating Kubernetes DRA with the realities of isolated zones.

We’re also seeing KVM gain snapshot and restore and suspend/resume, which brings it closer to production parity with Xen. SPIFFE/SPIRE support gets richer workload attestation, including image-signature verification, while our ongoing benchmarking work gives us a much clearer picture of where isolation costs performance, and where we can take that cost back. The direction was deliberately to make sure fewer platform-specific decisions are needed for operators, with better integrations inside Kubernetes, and a deeper set of features behind the isolation boundary.

We hope you’re as excited as we are.

AWS Bottlerocket Support Nears Production Readiness in Edera 1.13

Edera 1.13 significantly advances support for AWS Bottlerocket, making it easier to run Edera on this lightweight, immutable container-optimized OS without maintaining custom images. This release automates Bottlerocket artifact publishing, includes the Edera host container in release artifacts, adds Bottlerocket AMI builds, and improves image maintenance. We’re also continuing work on daemon restartability and state durability to ensure Edera can preserve critical state and restart cleanly in place. This builds on the early-access support introduced in a previous release and removes friction for teams standardizing on Bottlerocket, particularly those looking to combine Bottlerocket with Edera's KVM capabilities.

Richer SPIFFE/SPIRE Workload Identity with Image Signature Verification

The latest release brings SPIFFE/SPIRE workload identity closer to production readiness, enabling Edera zones to receive automatically managed, cryptographically verifiable identities. This release strengthens the Kubernetes integration, adds automated workload registration, and introduces Edera-specific workload attestation, as well as including support for verifying workload image signatures. Together, these enhancements let teams build identity and access policies based not only on where a workload runs, but on what is running and whether it can be trusted. This builds on the SPIFFE/SPIRE foundation introduced in earlier releases and paves the way for seamless integration with existing SPIRE deployments.

A Unified, Kubernetes-Native Helm Install and Upgrade Path

We’re bringing the entire Edera stack under a single, Kubernetes-native installation and upgrade path. One Helm chart now manages Edera components with consistent configuration and versions, while Edera licenses can be updated without rebuilding images or replacing nodes. In-place upgrades and ConfigMap-based configuration make fleet-wide updates as simple as a Helm upgrade, while removing the need for custom node images. The result is a simpler way to deploy, configure, and upgrade Edera at scale, all with less operational overhead and a smoother path to running Edera on standard EC2 and EKS infrastructure.

ARM64 Workload Isolation on AWS Graviton Bare-Metal Instances

We are excited to announce how we’re expanding workload isolation to modern ARM64 server platforms, including AWS Graviton bare-metal instances. We’ve brought Xen’s ARM support to SystemReady platforms, enabling Edera to boot on ACPI/UEFI-based ARM servers and securely pass through PCI devices with hardware-enforced DMA isolation. For customers, this means Edera can now run on the same high-performance, energy-efficient ARM infrastructure they’re already adopting, without the need for custom kernels or platform-specific changes. Graviton4 is supported from day one, bringing Edera’s secure workload isolation to AWS’s latest-generation ARM silicon.

Snapshot, Restore, and Suspend/Resume for KVM Zones

Edera 1.13 introduces snapshot and restore, suspend and resume support for KVM zones, alongside key security improvements. These enhancements advance Project Lunchbox’s goal of making secure, scalable AI agent sandboxing more practical, while bringing KVM closer to feature parity with Xen. Customers can choose the virtualisation platform that best fits their needs without sacrificing the operational capabilities required for production workloads.

Kubernetes-Native Memory Accounting for Isolated Edera Zones

Finally, the 1.13 release significantly improves how Edera and Kubernetes work together to manage memory. Kubernetes can now accurately account for memory across Copy-on-Write, ballooning, scheduling, and OOM conditions, giving the orchestrator a clearer picture of the resources actually available inside Edera zones. This creates a stronger foundation for running memory-sensitive workloads at higher density while ensuring Kubernetes can make informed scheduling decisions as zones grow, shrink, and come under memory pressure. The result is a more predictable, Kubernetes-native experience for managing memory across isolated workloads.

FAQ

What’s new in the Edera 1.13 release?

Edera 1.13 adds a single Helm-based install and upgrade path, moves AWS Bottlerocket support toward production, extends isolation to ARM64 on AWS Graviton, brings snapshot/restore and suspend/resume to KVM zones, enriches SPIFFE/SPIRE identity with image-signature verification, and tightens Kubernetes memory accounting for isolated zones.

Does Edera 1.13 run on AWS Graviton and ARM64?

Yes. Edera 1.13 extends workload isolation to ARM64 servers, including AWS Graviton bare-metal instances, by bringing Xen’s ARM support to SystemReady (ACPI/UEFI) platforms with hardware-enforced DMA isolation for PCI passthrough. Graviton4 is supported from day one, with no custom kernels or platform-specific changes required.

How does Edera 1.13 install and upgrade on Kubernetes?

A single Helm chart now manages the full Edera stack with consistent configuration and versions. In-place upgrades and ConfigMap-based configuration turn fleet-wide updates into a Helm upgrade, licenses update without rebuilding images or replacing nodes, and custom node images are no longer needed on standard EC2 and EKS.

What KVM capabilities does Edera 1.13 add?

Edera 1.13 introduces snapshot and restore plus suspend and resume for KVM zones, moving KVM toward feature parity with Xen. These changes advance Project Lunchbox’s goal of practical, scalable AI agent sandboxing and let teams choose the virtualization platform that fits without giving up production operational capabilities.

‍