CARLOS

CARLOS is an architecture for building software that is cheap enough to leave running forever, small enough to understand, sealed so tightly the operator is not a party to it, and yours to run. It was not designed. It was extracted — the same shapes kept appearing across a messenger, an email service, a social network, a file store and a training app, until it was obvious they were one thing being rebuilt five times.

It exists because the economics of building software changed. AI made the hard parts cheap, and in doing so made a category of system newly viable: software crafted for an audience of five, systems no company would ever have staffed, care applied to corners no budget ever reached. The Eleven Factors set out what such systems should promise. CARLOS is the shape that keeps those promises in code.

The premise in one line: treat AI as a factory, not a feature. Spend an extravagant machine, at length, to produce a lean artifact — one static binary, no build step, no dependencies, no JavaScript that isn't hand-written. The compute is spent once at the factory. What ships is small forever.

What the letters mean

Five claims, each of which a system either honours or doesn't.

Continuously Available Always there when someone knocks; not running when nobody does. An instance is spawned on the request that needs it and stopped when it goes idle. Most software is used a few hours a week and billed for a hundred and sixty-eight.
Replicated The box is disposable; the data is not. Every database streams to object storage from the first byte, and can move between machines under a lease that guarantees exactly one writer. Losing a server should cost a restart, not a history.
Lightweight One static binary with the database compiled in. No container required, no runtime to install, no bundler, no build step. Small enough that one person can read all of it, and cheap enough that running it for a handful of users is not a business decision.
Open Source-available and forkable, and — the part that is usually missing — actually runnable by the person who depends on it. If you can't run it yourself, you don't own it. Software built with AI should belong to the people it was built for.
Secure Not "we take security seriously". A specific, falsifiable claim: the server holds only ciphertext it cannot open, so publishing the entire database leaks no content. Last in the acronym, first in the architecture — every other letter is shaped around this one.

The one rule

If the server is compromised, the attacker gets nothing.

This is the constraint every other decision is downstream of. The server stores and relays opaque ciphertext plus key material it cannot open. It never sees plaintext and never receives a usable private key. Private keys live in browsers, and nowhere else.

Each person holds a keypair. Content is sealed under symmetric keys that are wrapped to each member's public key, so membership is the boundary and it is enforced by cryptography rather than by a permission check that someone can forget to write. Invite links carry a one-time secret in the URL #fragment — which browsers never send to the server.

The test is blunt, and it is the only one that counts: publish the entire database and see what leaks. In a system built this way the answer is metadata — who talks to whom, and when — and never content. That residue is real, and worth stating plainly rather than papering over; the point of the architecture is that it is all that is left.

The shape: a blind router, and one process per person

The front door owns identity. It knows nothing about what is behind it.

A CARLOS deployment is a small router and many instances. The router owns identity, sessions and routing, and knows nothing about what it routes to. An instance owns exactly one person's data and knows nothing about anyone else. They speak over a unix socket, and the socket is the boundary — an instance has no authentication of its own, deliberately, because the front door owns identity entirely and a second auth layer is a second thing to get wrong.

Blast radius

A panic, a runaway query, or a memory leak in one person's request path takes down one person's process. The next request starts it again. Nobody else notices. This is the kind of resilience you get from partitioning rather than from engineering, which is why it holds up under code nobody has read closely.

Hibernation is the real prize

Waking is lazy: a request arrives, the process is spawned, the request waits a beat. Sleeping is a sweep, not a timer per instance, so a thousand idle people cost one goroutine rather than a thousand. Stopping is a drain, never a kill: work in flight when the sweep loses patience still lands.

Spawning is locked per person, never globally — several requests arriving at once for someone asleep would otherwise each start a process against the same database file, fight over the lock, and delete each other's sockets.

Parking, and the single-writer lease

An idle instance can go further than stopping: its database leaves the box entirely for object storage, and comes back on the next request. That is only safe if exactly one machine may ever write it, so the lease and the manifest are one object, not two — a lock and a manifest in separate objects need two writes to move together, an object store cannot make two writes atomic, and the moment between them is precisely the window where a takeover reads a lock saying one thing and a manifest saying another.

Every state change is a conditional write against the version that was read. Two machines both trying to claim the same expired lease is the normal case, not the exotic one: exactly one write lands, and the loser is told it lost rather than being left to believe it won.

The failure this prevents is not a merge conflict. Two writers on an append-only log produce no conflict anyone notices — they produce a record that silently never happened, and everything derived from it computed against a history with a hole in it. Some data models fail loudly. This one fails quietly, so the lease has to be right.

Lean by construction

The artifact is small because the rules make it hard to grow.

One static binary. Pure Go, no cgo, SQLite compiled in. Copy it to a box and run it. Adding a dependency is a decision, not a default.
No build step, anywhere. The client is hand-written ES modules served directly. No bundler, no transpiler, no lockfile to rot. What you read in the repo is what runs in the browser.
One file, one concern — enforced. A hard line-count cap per module, checked by a test that fails the build. When a file trips the guard you split a concern out; you never raise the number. The cap only ratchets down. Every previous codebase that skipped this grew one do-everything file, and it cost real time.
Additive-only migrations. Idempotent schema changes, so deploying new code over an old database is always safe — which is what makes a thousand independently-versioned instances tractable at all.
Integers for anything that matters. Money, weights, counts. A float never touches a value a person will be held to. Display converts.

AI as the factory — and as a guest with a name tag

Extravagant machines, spent on lean artifacts.

CARLOS assumes AI wrote most of the code, and is arranged so that this is safe rather than merely fast. The discipline is not in the typing — it is in the guard rails that survive an author who does not get tired and does not push back.

Every session gets its own worktree and its own canary. Several sessions — human and machine — are usually in flight at once. Nobody builds in the main checkout, and shared hosts only ever run merged code.
Review happens on something deployed, never on localhost. A rendering bug that only a real browser engine exposes passes a unit suite clean, so the gate after every deploy is a headless engine failing on any console error.
Nothing lands untested. Every change carries the tests for what it adds; a bug fix carries its regression test. The line caps, the schema rules and the crypto invariants are all assertions in a suite, not paragraphs in a document — because a paragraph does not fail a build.

Where AI appears in the product rather than the factory, it is opt-in, never required, always disclosed. An agent is an ordinary encrypted member whose device is an operator-run sidecar holding its own key: it decrypts exactly the conversations it was invited to and nothing else. Agent code never runs inside the server process, and the sidecar is a pure outbound client with no inbound ports — so compromising the server yields neither the agent's keys nor the model provider's. Every path through the system works with the agent switched off.

Machine-authored text is marked 🤖 wherever it surfaces, including on this page.

Open, and self-hostable, and those are two different promises

If you can't run it yourself, you don't own it.

Publishing source is the easy half. The half that usually goes missing is that the thing is actually runnable by a person who is not the vendor: no proprietary control plane, no license server, no essential component that only exists in someone else's account. A CARLOS system is one binary and a directory. That is the whole dependency list, and it is deliberate.

Centralised pieces are allowed — push relays, discovery, backup stores — on one condition: they must be glue. Thin, blind, and replaceable. A relay forwards sealed bytes it cannot open. Anyone can run their own. The test is the subpoena, the seizure, the hack: when the central piece falls, the people inside lose at most some convenience, never a word they said.

Where it came from

CARLOS is being extracted from five systems that arrived at the same architecture independently, and are now converging on a shared one. The framework is the intersection, not the union — a shape has to earn its place by appearing more than once.

Eleven Messenger: End-to-end encrypted messaging with no logins and no passwords — just secret invite links. Where the model started.
Keymail: Email, but secure. Instances relay ciphertext and proofs; a compromised server holds nothing readable.
Woodstar: Pre-takeover Twitter on the same model. Source of the module-size discipline and the browser test harness.
Slopbox: An open, end-to-end-encrypted alternative to Dropbox.
Kass: A training app for personal trainers and the people they train. The first system built on CARLOS deliberately rather than by convergence.

The framework is early: the router, the activator, the parking lease and the object store exist and are under test, but they live inside the applications they were pulled from. Extracting them into something a stranger can adopt is the current work. This page describes the architecture honestly, including the parts that are not yet packaged.