Enclavia

Open-source crates that make up the Enclavia enclave runtime: the in-enclave services that run inside the EIF (Enclave Image File), the shared protocol types that describe the wire format between client and enclave, the client SDK (native and wasm), and the CLI.

Enclavia lets you run arbitrary Docker images inside an AWS Nitro Enclave (or a local QEMU debug enclave) and reach them through an end-to-end-encrypted channel that is anchored to a Nitro attestation. The hosted control plane (website, builder, router) lives in a separate, closed-source repository. The code that runs inside the enclave (which is PCR-measured and therefore part of the attestation contract) and the code that talks to it must be auditable, so it lives here.

See https://beta.enclavia.io for the hosted service.

Agents: skills/enclavia/SKILL.md is a machine-oriented guide to driving the enclavia CLI with --json. If you are an AI agent operating enclaves, start there.

Published packages

The client-facing pieces are published to the public registries:

• CLI: cargo install enclavia-cli installs the enclavia binary (enclavia-cli on crates.io), or nix run github:EnclaviaIO/enclavia#enclavia.
• Rust SDK: enclavia on crates.io (cargo add enclavia).
• Browser/Node SDK: @enclavia/client-wasm on npm (Node 22+, Deno, bundlers).
• Protocol types: enclavia-protocol on crates.io, pulled in transitively by the SDK and CLI.

Everything else in this workspace (the in-enclave binaries, dev tools) is consumed from git/Nix and is not on crates.io.

Crates

In-enclave binaries (run inside the EIF, reach the host over tokio-vsock):

• enclavia-server: Noise responder that terminates the encrypted channel from the router, forwards plaintext bytes to the inner container over loopback TCP, and dispatches signed control commands (upgrades).
• enclavia-egress: Outbound TCP daemon. Owns tun0, runs a smoltcp userspace TCP/IP stack, and dials egress-host over vsock for every accepted outbound flow. Enforces a deny-by-default allowlist of IP literals, CIDRs, and hostnames (resolved through an in-enclave unbound).
• enclavia-crypto: Key management. Talks to KMS over vsock and unseals the LUKS volume that backs persistent storage.
• nbd-client: NBD client that backs the encrypted filesystem on top of storage-host, and the anti-rollback enforcement point (pins volume freshness against the synchronizer).
• synchronizer: The storage anti-rollback oracle. A mutually-attested, Raft-replicated cluster of identical enclaves that tracks each volume's latest transaction id, so a malicious host cannot serve a stale (rolled-back) copy of the encrypted volume unnoticed.
• enclavia-chain-init: Boot-time hook that submits each boot/upgrade link of the enclave's attested history chain.
• enclavia-secrets-init: Boot-time hook that pulls the per-enclave secrets payload from the host and injects it into the workload's environment.
• synchronizer-names-init: Boot-time identity side-channel for synchronizer nodes (routing labels only; identity comes from attestation).

Shared / client-side crates (build for any target):

• enclavia-protocol: Wire types and Noise+CBOR responder helpers. Shared between the in-enclave server, the host-side router, and the SDK. Includes attestation verification, the upgrade-chain and custody helpers, and the mesh/egress hand-off frames.
• enclavia: Client SDK. Opens a Noise tunnel through the router's WebSocket, verifies the enclave's attestation against your pinned PCRs, and exposes the channel as an http-compatible client. Compiles for native targets and wasm32-unknown-unknown.
• enclavia-wasm: wasm-bindgen bindings over the SDK for browsers and JS runtimes (Node >= 22, Deno): connect(url, pcrs, opts), fetch(...), and raw openStream(...) byte pipes. Same attestation verification as native.
• enclavia-cli: The enclavia binary: auth, enclave lifecycle, image push, secrets, signed upgrades (managed or self-hosted YubiKey custody), reproduce, and a global --json mode. Also exposes a library face (enclavia_cli::{api, commands, config}); see enclavia-cli/README.md.
• enclavia-vsock: Small shared vsock plumbing used by the in-enclave crates.

Dev tools:

• mock-kms: A KMS Trent endpoint for QEMU dev wrappers and the local dev stack.

The host-side relays (egress-host, storage-host, mesh-host, ...), the WebSocket-to-vsock router, the control-plane API, the frontend, and the EIF builder live in separate repositories.

Build

This workspace is driven by Nix flakes and Cargo.

# One-shot Cargo build:
cargo build --workspace

# Or via the Nix dev shell (pins the Rust toolchain):
nix develop
cargo build --workspace

Individual flake packages:

nix build .#enclavia-server
nix build .#enclavia-egress
nix build .#enclavia-crypto
nix build .#nbd-client
nix build .#synchronizer
nix build .#enclavia-secrets-init
nix build .#enclavia-chain-init
nix build .#mock-kms
nix build .#enclavia        # the CLI binary
nix build .#enclavia-wasm

The in-enclave binaries only really run inside an enclave or QEMU. To exercise them end-to-end you also need the builder (which constructs the EIF). See https://github.com/EnclaviaIO/builder.

Synchronizer EIFs

The synchronizer is the one enclave whose image is built in this repo. There are two images. They are separate builds with separate PCRs:

Output	Architecture	Runs on	Synchronizer build
synchronizer-eif-nitro	aarch64	Graviton Nitro Enclaves (production)	enclave: full AWS Nitro CA chain checks
synchronizer-eif	x86_64	the local QEMU cluster (dev and CI only)	qemu: skips the CA chain; never for production

Both are defined only for x86_64-linux. The production image is cross-built on x86_64, kernel and init included, so anyone can reproduce its PCRs on an ordinary x86_64 machine:

nix build .#synchronizer-eif-nitro
cat result/pcr.json

Both images use the builder's minimal kernel (non-storage profile, no modules, NSM driver built in) and the builder's patched init. The kernels and the aarch64 init are built here from the builder's source (the pinned builder-src input) with the builder's own nixpkgs pin (nixpkgs-builder), by the builder's recipe, so they are the same derivations the builder exports. The builder is not a flake input here: its flake has an enclavia input of its own. Everything else in the image is static: the synchronizer, synchronizer-names-init, nitro-timesync and busybox. The init script runs under busybox sh. The build fails if any binary in the image is not a static ELF for the image's architecture. See nix/synchronizer-eif.nix.

Reproducibility

The whole point of this repo being open source is that anything PCR-measured inside the EIF must be buildable from sources you can audit. Every crate here is part of that perimeter (or is consumed by code that is, via enclavia-protocol).

The CLI's enclavia reproduce command pins to the same flake.lock the backend used when building an enclave, so you can verify that a given attestation came from the sources you expect.

License

Dual-licensed under either:

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contributing

See CONTRIBUTING.md. Security reports go to security@enclavia.io.