Tech

incus-compose is a drop-in replacement for docker compose that runs your compose.yaml on Incus, with the full Incus API as an escape hatch when you need more than the Compose spec covers. Twelve days for 1.3 to come: backup, port-forward, and all the commands you might have been looking for. Full release notes: incus-compose 1.3 has been released on the Linux Containers forum. Two bits that did not make the announcement. run was a lot of hassle to create Incus has no “start this, tell me what it exited with”. An instance runs its entrypoint and the exit status goes nowhere. ...

incus-compose backup takes the storage volumes of a project, keeps them, and puts them back. Here is five and a half minutes of it on the immich example — postgres, redis, server, microservices, machine-learning, and three volumes between them: asciinema.org/a/1263992. Every timestamp below opens the recording at that moment, so you do not have to watch the whole thing. It is one take. There is a ^C out of backup create while it was still waiting on a healthcheck, and a [warn: resource is already running] near the end. ...

In The Ones I wrote down a table of imaginary agents. The top row was the boring one: an agent that asks what a thing is for, and cannot propose and cannot cut. Yesterday I ran it by hand. No custom runner, no daemon, no theones binary. Two terminal sessions, two log files, and a real task on incus-compose. It found real defects and the work landed. The interesting part is where the constraint came off, and that I did not notice at the time. ...

None of them exist. What follows is a group of imaginary agents that would help me work better. I am writing them down because writing a thing down is how I find out whether it is worth building, and because this group is cheap to describe and expensive to make. Where they come from After a session with an agent I ask it for a written account of how the session went. There are 132 of those now, going back to January, and read together the failures in them are not varied. They are a small number of things, repeated: ...

One of the session write-ups in my repo opens like this: Session ended with a revert and nothing shipped. It is written as a confession. Nothing shipped is the normal state of a session, and it always has been. What shipped means On a branch, it is a draft. On main, it is merged. It is only shipped when it has a version tag. Nothing else counts. I keep that narrow on purpose. It is the only line in the whole process where the cost of being wrong changes, and everything either side of it behaves differently. ...

In a review session an agent told me the plugins in the chain must not trust each other. Treat each one like a foreign API: check what arrives, and defend the chain against a plugin that misbehaves. It was not a careless suggestion. That is what you do at a boundary you do not control, and it is the right default for most of the code anybody works on. I still said no, and writing down why took longer than saying it. ...

One of the architectural rules in the AGENTS.md of incus-compose is: Constraints outside, freedom inside. A unit is predictable from the outside: what it receives, what it returns, and which effects may escape are fixed. Inside those constraints, it is free to reconnect, coordinate goroutines, or replace its machinery without involving its callers. An operation may send messages or write files because those are its purpose. The problem is an incidental effect becoming somebody else’s responsibility: ...

It started with an LLM agent documenting the boundaries for me instead of building them. It was about concurrency, and what came out of it was a comment: which call may come from which goroutine, what has to be locked first, what to watch out for. All correct. All friendly. All just text. A boundary that lives in a comment isn’t a boundary. It’s a request. It holds as long as the comment is read and remembered. I just don’t want to remember; static linters should. Safe at any time, by any reader. ...

A storage pool in Incus is a driver and a source. There are several drivers: zfs, btrfs, lvm, ceph, dir. dir is the most boring one, a directory. And a directory is allowed to be a tmpfs mount. mount -t tmpfs -o size=32g none /mnt/tmpfs incus storage create tmpfs dir source=/mnt/tmpfs From here on, every instance that starts on this pool lands in memory. Create incus launch images:debian/trixie runner --storage tmpfs Back up incus publish turns the instance into an image. If it’s still running, Incus demands --force. The aliases rotate the generations: ...

Six and a half months after the first announcement, 22 betas and 2 rcs later: incus-compose is 1.0.0. Three Rewrites ended on a line I want to pick back up. “go-orb: three years of work. No users. incus-compose: two months. Several.” That stayed true. People ran it, broke it, filed issues — and the core from The Core Should Know Nothing just kept absorbing what they threw at it. New resources, new edge cases, no changes to the core itself. ...