Announcing beam-init - a Rust init process for agents

Agents start servers, jobs, and background helpers. A harness can track those processes, collect logs, and stop them through shell commands or background task tools. We built beam-init to provide those capabilities at runtime through an API. It is a lightweight init process and service manager for containers, microVMs, and agentic workflows.

When we started building our product, Beams, a runtime for agents, we planned to package an existing init system.

Why would you need an init system in a container or microVM anyway?

Inside a container or a microVM, the first process runs as PID 1. Its responsibility is to inherit orphaned processes and reap terminated children. Without a dedicated init process, the application must handle that responsibility. Without reaping, zombie processes retain entries in the process table and can eventually exhaust process limits.

“How hard could it be? Let’s choose a decent init system and package it in a container.” That’s what we thought as well, but things turned out to be a bit more complicated.

First, we looked at systemd. However, a privileged security context and CAP_SYS_ADMIN when running on Kubernetes made it unsuitable for our deployment.

Another candidate, s6-overlay, looked promising, but its focus on service definitions and command-line tooling did not suit us.

Moreover, both systemd and s6-overlay are written in C, which gave us pause.

We went back to the drawing board and set out the design requirements for an agent- and microVM-friendly init system:

• Lightweight memory and disk footprint.
• API for service management.
• Written in a memory-safe language and audited, so we don’t compromise our organizational security while maintaining the same security standard for our customers.

We chose Rust for its combination of safety, performance, and low-level system access that are valuable for a process running as PID 1 and managing other processes.

We are not experts, so we partnered with Tweede golf, the best Rust experts in the field we know, to build beam-init. Their engineers implemented much of its core functionality, including process reaping, the API for controlling the service lifecycle, logging, and interactive terminal support.

We intentionally kept our dependencies minimal and only used well-known, tested crates to mitigate supply chain risks. To make sure we are not missing anything critical, we partnered with Doyensec to audit beam-init. Their report rated all issues as medium severity or lower and showed that most issues involved denial of service, while a few others were due of improperly sanitized user input.

Here is what we ended up building:

beam-init combines these init responsibilities with service management.

Agents can inspect a service’s current state and read its recent logs to diagnose failures or follow ongoing work.

Stopping a service terminates its processes, freezing a service suspends its execution, and thawing it allows the service to continue its work.

Interactive or TUI-based applications in a remote environment can be interrupted by an unreliable connection. beam-init addresses this problem by allocating a pseudoterminal for the lifetime of the service, allowing you to reconnect after a disconnection.

Here is an example of Claude running in a PTY-enabled beam-init service:

beam-init is licensed under Apache License 2.0, and you can find the code at https://github.com/gravitational/beam-init.

We think beam-init is an important missing block for an independent AI ecosystem, and we would like more projects to adopt beam-init!

Every microVM we ship via Beams at https://www.beams.run has an agentic container powered by beam-init.