tank-os - The Right Way to Run AI Agents on Linux
tank-os
A Five-Commit Demonstration
In April 2026, Sally O'Malley at Red Hat's Emerging Technologies team
published a project called tank-os at
github.com/LobsterTrap/tank-os. Five commits. Eighty percent shell,
twenty percent Containerfile. MIT-licensed. Explicitly not a Red Hat
product, per the disclaimer on the accompanying blog post.
What tank-os demonstrates is the cleanest agent-hosting architecture I
have seen. It does not require new tooling. It composes primitives
that have been quietly maturing in the Fedora and Podman ecosystems
for years. The result is what an AI agent host should look like in
2026, packaged small enough that the architecture is legible at a
glance.
This post is the reading of why it is correct.
Three Architectural Choices
fedora-bootc as the OS layer. bootc turns an OCI container image
into a bootable Linux operating system. The Containerfile that defines
the image defines the entire OS: kernel, init, root filesystem.
Upgrades are sudo bootc upgrade, which pulls a new image and reboots
into it. Rollbacks are sudo bootc rollback. Both are transactional.
Most of the filesystem is read-only. Configuration drift, the
historical failure mode of any managed Linux fleet, is structurally
prevented because the OS layer has no mutable parts worth speaking of.
Rootless Podman with Quadlet for the runtime. The agent runs as a
non-privileged user, inside a rootless Podman container, managed as a
systemd service through Quadlet. Quadlet ships with Podman and turns
systemd unit files into container definitions. The result is a
service that starts on boot, restarts on crash, logs to the journal,
and integrates with every systemd primitive an operator already
knows, while the agent process has no path to root on the host.
service-gator for scoped credentials. This is the piece the agent
security community has been asking for and almost nobody has shipped.
service-gator sits between the agent and any external service it
talks to (GitHub, JIRA, the company wiki). The agent calls the
gateway. The gateway holds the actual credentials and enforces scope.
The agent never sees the raw token. When the agent is compromised —
and the spring 2026 supply chain attacks made clear this is a matter
of when, not if — the attacker reaches the gateway's filtered view,
not the underlying credentials.
A final detail worth noting: no secrets are baked into the image. The
image is fully shareable. After boot, secrets are injected into the
running container through Podman's rootless secret store.
1printf '%s' "$OPENAI_API_KEY" | podman secret create openai_api_key -
The same image can be deployed to a hundred machines, each with its
own per-instance secrets injected at provisioning. Image is the
artifact, secrets are operational state, the two never touch in the
registry.
Why This Composes Correctly
The three choices are independently unremarkable. bootc has existed
for two years. Rootless Podman is older. Quadlet has been the
systemd-Podman integration since 2023. The gateway pattern is a
decade old in API design.
The interesting part is the composition. The image declares the
system. The Quadlet unit declares the workload. service-gator
declares the permission scopes. There is no imperative state that
accumulates during the host's lifetime. The agent runs isolated and
restartable. The OS is transactional and rollback-able. The
credentials are scoped through a gateway, not held directly.
These properties together describe what production-grade application
hosting has looked like in sophisticated infrastructure organizations
for the last decade. tank-os is the demonstration that the same
discipline applies to agents, with no new tooling required.
The Honest Limits
tank-os is Emerging Tech. Five commits. No commercial support. The
image ships with OpenClaw as the specific agent runtime; adapting it
to a different runtime means forking the Containerfile and reworking
the wrapper scripts. The image-based model trades flexibility for
predictability, which is the correct trade for production and
sometimes the wrong trade for development iteration. The
single-purpose-host deployment model fits edge devices, agent farms,
and dedicated inference hosts. It does not fit shared workstations.
None of this is a reason to dismiss the architecture. All of it is
context for understanding what it is.
What to Take From It
Three things, regardless of whether anyone actually deploys tank-os.
bootc as a deployment primitive is now on the table for serious work.
The Fedora upstream is mature enough. The RHEL Image Mode path is
production-grade. Any workload where configuration drift would be
operationally expensive is a candidate.
Quadlet is the right systemd-Podman integration for most container
workloads short of full Kubernetes. The docker-compose stacks most of
us run would be better expressed as Quadlet units, both for
operational simplicity and for the lifecycle integration with the
rest of the system.
The credential gateway pattern is non-negotiable for any agent that
touches anything non-trivial. The default of handing an agent a raw
Personal Access Token is the agent-infrastructure equivalent of
running services as root. service-gator is the single-machine
implementation. MCP Gateway is the production-scale implementation.
Either is infinitely better than the default.
Closing
The interesting projects in AI in 2026 are not the frontier model
releases. They are the small, careful, infrastructural projects that
take the new workload seriously and apply existing engineering
discipline to it. tank-os is one of these. The repository is at
github.com/LobsterTrap/tank-os, the image at
quay.io/redhat-et/tank-os:latest. Pull it. Read the Containerfile.
Notice that what it does is not complicated. Notice that what it
produces is right.