Coffey Labs

Coffey Labs

Infrastructure, maintained in public.

Open-source infrastructure — mail, observability, and the systems tooling around them. Copyleft-licensed without exception, and open to inspection line by line.

Every one of these was built to solve a problem on my own machines

Nothing here started as a product. Each project began because something needed doing on infrastructure I run myself and the tool for it either did not exist or did not do the job: a Stalwart server needed a client, that server needed upgrading without losing anything, the same administrative jobs kept coming round by hand. They were written to be used, by me, on systems I could not afford to break — and then published because a problem worth solving once is usually somebody else's problem too.

That origin is worth stating plainly rather than dressed up, because it tells you what to expect. These are tools in daily use by the person who wrote them, which is the reason they are careful about the things the approach page describes. It also means they are shaped by one set of requirements: if your situation is different, the honest answer is that you should read the code before depending on it. All of it is there to read, which is the next point.

Every project here sits underneath something that matters — a mail server, an incident, a machine somebody has to log into on Monday. Software in that position gets read exactly once: at 3 a.m., by whoever is holding the pager, after it has already done something surprising. That is the moment the license stops being an abstraction. You can either open the file that misbehaved or you can open a support ticket, and only one of those is a plan.

So the projects are copyleft, and the interesting part is the without exception. The convention in this space is to publish the core and hold something back — the multi-tenancy, the directory integration, the alerting — either behind a paid tier or under a license that permits reading but not much else. Cairn OBS ships its enterprise/ directory under the same AGPLv3 as the rest of the tree. There is no feature gate to find, because there is nothing behind it.

The second thing these projects have in common is that they try to own as little as possible. ihasmail keeps no database and, with IMMUTABLE=1, no writable filesystem: everything durable belongs to the Stalwart server that already has a backup story, and the client is disposable. stalwart-migrator does its work and leaves. The scripts use base utilities and nothing else. Depending on one of these should not mean inheriting a new thing to operate — the point is to remove work, not to relocate it.