Node0, in the Open

Node0 went online on 20260630. On 20260913 it became production-ready, which is a different thing: built, monitored, backed up and documented, with most of the runbooks written between those two dates. Today the documentation is public, at oznog.com/node0 , with the source in a repository anyone can clone.

What is there #

Three doors, because people arrive with different questions.

As it stands is the site as captured on 20260920, layer by layer: the rooms and racks, the edge, the fabric, the bootstrap boxes, storage, compute, services, the agents, observability, power, and how it is operated. Each layer page says what the layer is for, how it is built, the decisions with their trade-offs, what broke, and the state on the day. The figures come from one dated capacity file, read from the inventory and from each host, so the same number appears the same way everywhere.

The lessons are 116 of them, in six themes, each written as what happened, what it cost, what changed and the check that now exists. Alongside them are the twenty-seven rules the agents operate under, most of them drawn from these lessons and a few from incidents kept back. These are the pages we would have paid for a year ago. A drive that passes a health check at rest is not cleared for service. A dead-man’s switch is a design document until it has proved itself by being killed. Most of them cost us a day or more; a few cost nothing because a careful write-up found the gap first.

The seed is the same pattern at the size it starts: a laptop with backups already running, then one box, then a box for the agent, then the core, then compute, then the edge and a second site. Six rungs, each with what to buy, what to do and what it costs, and a ledger of what has actually been run. Rung 0 is in progress as we write.

Around those, the diagrams are drawn from data files rather than by hand, the photographs are of the real rooms, the site pages name their source and the date of the capture they describe, and every lesson carries the dates of its own incident.

Why publish it #

Sovereign infrastructure is the ground the rest of Oznog stands on. Relational Core is being built on it because a map of what a person seeks, offers and protects should never leave hardware that answers to them. We think many more people and organisations need the same ground, and that the reason they do not build it is rarely money. It is that nobody has shown them a worked example with the mistakes left in.

So the mistakes are left in. The pages are derived from the private site through a checklist: no addresses, no credentials, no serials, no paths, the finance system by shape only, humans other than Christoph by role. Everything else is there, including the fortnight a backup layer ran green while protecting nothing, and the firewall login page that faced the internet for longer than anyone recorded.

Who it is for #

It is written to be read by a person and used by their agents. Point an agent at the section, tell it what you have on the bench and what you need the site to do, and it will find the rung to start on, the decisions that transfer, and the lesson that would otherwise cost you the same time it cost us.

Three sizes, and the pages serve each.

• A seed. One laptop and one box, for a person or a small team who wants their data, their backups and their first local model on hardware they hold. Start at rung 0. Most of the design carries down unchanged: the backup rule, the notification path, the inventory as the source of truth.
• A site like this one. Pulled enterprise hardware, a few racks, a fabric, a storage cluster and a set of GPU hosts, run by a small group and their agents. Read As it stands for the shape and the lessons for what the hardware will do to you.
• Larger. Node0 runs on one fibre line and battery, not two providers and a generator, and says so. The pattern scales past that; the guarantees do not, and a larger site buys them. What transfers is the discipline: every alert names its runbook, every backup is proven by restoring it, a dated capture is what the documentation describes.

What we ask #

Build one. Tell us what the pages got wrong or left out, because the next capture is where that goes. The content is CC BY 4.0 and the tools are MIT, so take what is useful and keep the notice. If you are building something privacy-critical and aligned, and would rather build it here than alone, the incubator begins in Q4.