Aurae puts SPIFFE identity and PID 1 on the same node agent

The README's status block forbids production use

Start with the warning, because it conditions everything else. The Project Status section of the README reads, in blockquote form: "STILL IN EARLY DEVELOPMENT!", "The Aurae project and API can change without notice", and "Do not run the project in production until further notice."

The release record backs that up. The single recent release is v0.1.0-aa.1 from 2023-02-03, an alpha-suffixed tag that has not been superseded by anything newer in the tag list. The repository itself is not archived and its last push was on 2026-09-28, so code is still landing; the gap between an active default branch and a three-year-old release tag is the real signal here. Activity is not the same thing as a usable artifact.

Two things the project is clear about. Contributors do not have to know Rust, and the README points at a getting involved document. And Aurae is a member of the Nivenly foundation, which is the sort of institutional detail that matters for a project in this state, since the governance outlives any individual maintainer.

The framing in the README is also worth quoting directly, because it is unusually modest for a systems project: Aurae's aim is to be "the most loved and effective way of managing workloads on a node", positioned as something that complements higher order schedulers and control planes such as Kubernetes rather than replacing them.

Two binaries: auraed owns PID 1, AuraeScript owns the API surface

The architecture is two pieces, and the README is precise about the division. Auraed is the runtime daemon, deployed for memory safety as the generic system's runtime daemon. AuraeScript is a Turing-complete scripting language built on TypeScript, and its library "automatically generates itself from the pre-defined `.proto` files defined in the Aurae standard library".

That generation step is the interesting design choice. The `.proto` files are the core definition of both the runtime and the standard library, and the build process uses them to produce the client library. The same section notes that AuraeScript "directly embeds Deno source code to provide an SDK and the functionality to attach remote clients". So the scripting layer is a Deno runtime with generated stubs, not a separate protocol implementation, which is a good deal of leverage for a project this early.

#!/usr/bin/env auraescript
let cells = new runtime.CellServiceClient();

let allocated = await cells.allocate(<runtime.AllocateCellRequest>{
  cell: runtime.Cell.fromPartial({
    name: "my-cell",
    cpus: "2",
  }),
});

The generated client shape is visible in the call: `runtime.CellServiceClient`, then request messages built with `fromPartial`. The Cargo workspace confirms the split at the crate level.

[workspace]
members = ["aer", "auraed", "auraescript", "client", "ebpf-shared", "proto"]
exclude = ["ebpf"]

The TypeScript file format, the README says, replaces static manifests such as the YAML file format for direct interactions with a running system.

Cells are the partitionable unit, and the examples show the knobs

Aurae's idea of a workload starts with a cell. By introducing Aurae cells on top of a Linux kernel, the README says, "the control of each internal runtime process on a given node becomes possible", and auraed "maintains ownership of every process by managing everything from PID-1 to nested processes".

A cell request carries a name and a CPU count, as the TypeScript snippet shows, and the `examples/` directory is where the rest of the surface is visible. There is `cells.ts` for the basic case, then files that each isolate one dimension: `cells_isolated_network.ts`, `cells_isolated_processes.ts`, `cells_isolated_processes_and_network.ts`, `cells_memory.ts`, `cells_quota.ts` and `cells_output.ts`. There is also `cell_validation_errors.ts`, which tells you the server rejects malformed cells and says how.

The rest of the example set covers the other workload kinds the README lists: `virtual_machines.ts`, `pods-cri-nginx.ts` and `discovery_discover.ts`, plus `grpc_health.ts` for a health check. `aer/` is the CLI in the workspace, matching the CI workflow named `make aer-test`.

Process isolation is backed by eBPF rather than by naming conventions. The repository holds `ebpf/` and `ebpf-shared/`, with `ebpf` excluded from the Rust workspace because it is its own build. The Makefile pins a VM kernel at 6.1.6, which is a hint about the kernel surface the project expects to work against.

Identity extends SPIFFE down to the Unix domain socket

The authentication story is where Aurae is most specific, and it is the reason to look at the project even if you never deploy it. The README says Aurae extends SPIFFE and SPIRE backed identity, using x509 mTLS for authentication and authorization "in a distributed system down to the Unix domain socket layer". The Introduction repeats the claim from the other direction, saying Aurae supports multi-tenant workloads and enterprise identities all the way down to the socket layer.

That is a stronger claim than most node agents make, and it is worth being precise about what it does and does not say. It does not describe a policy language, a token format or a rotation procedure. It says the SPIFFE model is carried to the socket, which means a local client can be identified by the same identity as a remote one. Whether that is sufficient for your threat model depends on how your socket is exposed, and the README does not document the socket path or its permissions.

The same section contains the project's clearest architectural rule, and it is a constraint rather than a feature. Under Principle of Least Awareness: "A single Aurae instance has no awareness of higher order scheduling mechanisms such as the Kubernetes control plane." The node agent is meant to be ignorant of the scheduler. That is what lets it complement one, and it is also what means it cannot, on its own, make placement or bin-packing decisions.

The runtime API itself is exposed as a gRPC service through the Aurae standard library, with a V0 API reference holding the current library definition. V0 is not a stable-contract label.

The getting started guide is commented out in the README

There is an honest gap here. The README contains a Getting Started section, but every line of it sits inside an HTML comment: Building Aurae from Source, Dependencies, Prepare the Environment, Aurae Quick Start, Running the Daemon, Running your first Cell, and Developing on an M1 with Environment, VM Setup and CLion Setup. None of it renders, so the README as published gives you no install command and no first-run daemon invocation.

What you can use instead is the Makefile and the CI workflow names, which are the only executable guidance in the repository. The badges at the top run `make auraed-test` on `ubuntu:latest`, `make auraescript-test` on `ubuntu:latest` and `make aer-test` on `ubuntu:latest`, so those three targets are known to work in a container.

make auraed-test
make auraescript-test
make aer-test

The Makefile itself is where the toolchain assumptions sit. It pins `buf_version = 1.63.0` for protobuf generation, `cri_version = release-1.26`, `clh_version = 30.0`, and `vm_kernel = 6.1.6` with a `vm_image` pointing at an Ubuntu focal cloud image. It also defaults the OCI tool to `docker` with `DOCKER_BUILDKIT=1`, and decides whether cargo runs under sudo: if `id -u` is 0 it uses `cargo`, otherwise `sudo -E `which cargo``. That last line is a quiet signal that building auraed is expected to need root, which is consistent with a daemon that owns PID 1.

There is a `hack/` directory and a `Makefile` target family, plus `flake.nix` and `flake.lock` for Nix users. Between the commented-out guide and the Makefile, a new user is expected to be comfortable reading build files rather than following steps.

How this differs from systemd, CRI-O or a node agent you write

The comparison worth making is not against Kubernetes, which Aurae explicitly sits under, but against the two things already installed on a Linux node: systemd and a CRI implementation.

Aurae overlaps with PID 1 supervision and static configuration, while providing a TypeScript surface and extending SPIFFE-backed identity to the socket layer.

The repository's `pods-cri-nginx.ts` example indicates an intended pod and nginx integration.

The third option is writing the node agent yourself, which is what Aurae is really a reference for. You get roughly the same gRPC surface with an API you own, no 2023 alpha tag, and no dependency on a project that asks you not to deploy it. The case for adopting Aurae over writing one is narrower than the mission statement: it is the SPIFFE-to-socket work, the eBPF isolation, and the cells abstraction, all of which you would otherwise have to build.

Editorial conclusion

Aurae is worth reading for anyone building a node agent and worth running only for experiments, because the README's own status block says the project and API can change without notice and asks you not to deploy it. Anyone already on Kubernetes has systemd and CRI, so the missing piece here is a second daemon to operate, not a capability. Before evaluating further, check whether the v0 API reference still matches your use case and whether a single release tag from 2023 is acceptable as your stability signal.

Frequently asked questions

Official sources

1. aurae-runtime/aurae on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases