We don't run our infrastructure that way, so this week we stopped running our chat that way. Atelium's team server is now defined in a file, in git, and a small program reconciles the live server to match it.

What "as code" means here

The whole server is one declarative config: roles, categories, channels, who can see what. A provisioner reads the live server, compares it against the file, and applies only the difference. Point it at an empty server and it builds everything. Run it a second time and it says, simply, in sync.

That second run is the entire point. Discord has no "desired state" endpoint — every tool that manages it, ours included, has to read what exists, decide what should change, and make exactly those changes and nothing else. So the heart of the thing is a pure function with a deliberately boring signature:

// Given the live server and the file, compute the difference.
function reconcile(current: ServerState, desired: Config): Action[]

Everything else — logging in, creating a channel, denying a permission — is plumbing around that function. Because it is pure, we can test the hard part (does it notice a renamed role? an extra channel? nothing at all?) without ever touching Discord. The plumbing we trust to a single live dry run that prints the plan before a thing happens.

The decision that mattered

The one choice worth keeping: every channel is hidden by default. The everyone role can see nothing; the team role can see everything. That sounds austere for a three-person server, and today it is. But it means the day we invite a client into a single project channel, that is one line — grant them their category — and there is no path for them to accidentally see the rest. The safe thing and the easy thing become the same thing, which is the only arrangement that survives a busy week.

There is a smaller lesson folded in, too. A bot cannot own the server it manages, and in Discord a role's position outranks even administrator rights — so a human still has to do two clicks no script is allowed to. Worth knowing before you assume automation can do all of it.

Why bother, for a chat server

Because it will drift. Someone makes a channel at 11pm, someone loosens a permission to unblock a call, and a month later the server is a place nobody designed. Code is how a shared space stays honest: the file is the intent, the dry run is the diff, and "in sync" is a real answer to the question "is this still what we meant?"

It is the same reason this website is flat files and the database is git. A room you can rebuild from a file is a room you actually understand. Ours rebuilds in about twenty seconds, and we will never again squint at a channel wondering why it is private.

If that is the kind of thing you like to read about, subscribe below. We don't email often, and when we do it will be worth opening.

Atelium is a small company with two products and one conviction: that software made with care is worth more than software made at scale. Workbench is our unified surface for working with AI. DocuSpot is our document automation platform for operations teams. Both are built the same way, by the same small team, with the same refusal to ship things that are not good enough.

What this journal is

This is where we write about the work. Not launch posts, not press releases. The actual decisions: why we chose flat files over a database in one place, why a feature did not make the cut in another, what we got wrong and then fixed. The thinking behind crafted tools, in public.

Why bother

Because the software we admire was made by people who wrote down how they thought. We learned the craft from their posts. This is us paying that forward while we build.

Expect code, too. When a decision comes down to a few lines, we will show the lines:

// The whole site is flat files. The "database" is git.
Route::statamic('journal', 'journal.index');

If that sounds worth your time, subscribe below. We will not email often, and when we do it will be worth opening.