The Path › Chapter 7 of 9

Deploy on awnix

immutable Linux for machines where agents write software

About 45 minutes · for operators · bricks: awnix · awdk

Teach

What "immutable" means

An immutable Linux is one where /usr — the folder containing all system software — cannot be changed at runtime. A traditional computer is like a notebook: you write in it, erase things, write over them. An immutable system is like a printed book: the words never change by hand, and the only way to make a new version is to print a new book and keep the old one.

Every time your agent runs code that changes the system — installs a package, updates a config, patches a binary — that change becomes a NEW IMAGE. You can compare the two, see exactly what changed, and if something went wrong you can bootc rollback back to the printed book you trusted.

Cloud-init makes key-only login actually usable

An awnix machine has NO PASSWORD. Access is by SSH key only. You might think that sounds impossible — what if you lose the key? The answer is cloud-init: a service that runs once on first boot and injects whatever SSH keys you tell it to. On a cloud image you launched, your launch keypair arrives automatically. On bare metal you place a key yourself. Either way, nobody ever types a password, which means there is nothing to leak.

Two things must be true together or the whole idea breaks:

  • cloud-init must run and inject the key
  • NOPASSWD sudo must be enabled, so the account can administer the box without a password (the same setup ec2-user and ubuntu use)

What bootc does

bootc — the bootable container system — moves a container image from podman run to bare metal. You build an image on your laptop, push it to a registry, and a machine boots it directly. Every boot is atomic: the system either completes or rolls back, never a partial state. An update that goes wrong is bootc rollback, not an afternoon of recovery.

The aw tools are preinstalled

awnix ships 19 of the aw* tools ready to import: awgit (leases), awgraph (call graphs), awrelay (messaging), awseal (signing), and 15 others. Your agent does not have to install them — they are already there. That is the point of a base image: the guarantees are built in, and every agent on top gets them for free.

Layering an agent on top

An agent is three things:

  • The awnix base (immutable, atomic updates, built-in tools)
  • awdk — the agent runtime
  • Your skills, packs and credentials

A Dockerfile that layers on top looks like:

dockerfile
FROM awnix:latest
RUN pip3 install --no-cache-dir awdk
# ... your packs and credentials

The base is read-only. Your agent runs as a service (using the unit template in the awnix repo), and when it needs a new version, you rebuild the image and bootc upgrade.

Do

1
bash
git clone https://github.com/Aitherium/awnix

You should see: a folder named awnix with a Containerfile inside

If not: Install git (git-scm.com) and open a new terminal.

2
bash
cd awnix

You should see: your prompt shows the awnix folder; the build below runs here

If not: The Containerfile is in this folder; the build must run from inside it.

3
bash
podman build -t awnix:latest -f Containerfile .

You should see: an image named awnix:latest, built from the awnix repo you cloned

If not: Install podman (or Docker - docker build works the same). Clone https://github.com/Aitherium/awnix first and run this inside it.

4
bash
podman run --rm awnix:latest awgit --version

You should see: a version - proof the aw* tools are preinstalled in the base

If not: If the command is not found inside the image, the build used a different Containerfile. Rebuild from the repo root.

5optional
bash
bootc status

You should see: on a machine BOOTED from the image: the running image and the rollback target

If not: Only meaningful on a box that booted from awnix (the ISO or a cloud image). Inside a container it is absent, and that is expected.

Check you are done

bash
podman run --rm awnix:latest awgit --version

You should see: a version string

What you learned

One estate, 8 doors

These projects are organs of the same system — the same identity plane, the same agent runtime, the same operational discipline. Follow any of them.

the osaitherium.comThe Living OS these four repos are cut from. Open, no login.pythonAither ADKBuild AI agent fleets — 3 lines, any backend, local or cloud.markdownawskillsPortable agent skills — self-contained procedures an agent loads on demand.markdownawknowledgeHow to run a coding agent so the result survives — the laws, with evidence.cudaaitherkvcacheNear-optimal KV cache quantization for LLM inference — sub-byte compression.powershellAitherZeroPowerShell 7+ automation framework — numbered, self-describing scripts.writingThe BlogHow all of it is actually built, measured and operated.pythonawrunA priority-aware queue and dispatcher for agentic runs and ad-hoc CI builds. It also judges whether the runner pool is big enough for the queue it is draining, and can ask a host to grow it -- reserving capacity is zero-sum, so a saturated pool needs more of it, not a different share of it.

The ecosystem this belongs to

Every Aitherium repository publishes an aither-manifest.json beside its page, and each surface reads all of them — so the network is browsable from any node in it.