Give the AI
a PC of its own.

Everything the Independence part stands up has to run somewhere. Decide where, first.

2-01 drew the map: the layers bundled inside Microsoft and Google, untied into open tools. This chapter is about the machine those tools sit on. There is one move. Turn one company PC into Debian and hand it to the AI. Give the AI a PC of its own.

One machine does everything

The public website, the in-house tools (auth, documents, mail, meetings, scheduling, the code repository), and the AI's own work all go on the same machine.

There is no reason to split them at the start. Every extra machine multiplies the configuration and the updates. And the AI diagnoses and repairs faster when it can see the whole machine from inside. When the load outgrows one box, split it then.

The one exception is the self-hosted LLM set up in 2-16. It goes on a separate server. It needs a GPU and a lot of memory, which nothing else here does.

Build on Debian, with apt and systemd

The OS is Debian. Python and apt are there from the start, and git is one apt line away. Updates never reboot the machine on someone else's schedule.

The services the following chapters stand up are installed with Debian's apt and run under systemd. Anything apt does not carry is installed as the single file its project publishes, and registered with systemd. No Docker.

Docker is a tool for distributing, not for building. It is a box that lets someone else run what you made, unchanged, in their environment. When you build on your own machine and run it there, there is no one to distribute to. Isolation is covered by separate users and systemd's restrictions; rebuilding, by configuration in git and copies of the data. Concretely, there are three reasons not to use it.

• One update stream — what apt installs rides Debian's security updates, and one apt upgrade raises it all. Containers add a second job: tracking the version of every image
• The AI sees everything directly — configuration in /etc, logs in journalctl, data in known places. A container adds a layer of volumes, networks, port mappings, and mismatched user IDs, so every diagnosis and every fix happens in two places, outside and inside. In development, where you build and fix over and over, that layer is the cost
• The firewall holds — Docker diverts traffic to a published container port before it reaches ufw's rules (Docker's own documentation, checked 2026-10-05). The rule "only 80, 443, and ssh are open" does not reach a container's ports

The exception is set from the distributing side too. Something whose project ships it only as a container is received as that container and run. Use only the official image, and never build one of your own. An image with no one to distribute to only adds things to keep and places to fix.

Install a desktop and leave it running

Install the desktop environment (GNOME) as well, and leave it running. Do not assume a server needs no screen. Some of the work you want the AI to do requires one.

• Open a document on screen and read the values out of it
• Look at a page you built, in a real browser

When a person needs to look, they connect to that desktop from their own PC.

Hand the AI root

The AI does all the server configuration: installing, configuring, running, repairing. Every one of those is work in commands and files, and the result can be checked mechanically. It falls squarely inside what 1-01 described as a domain where the rules are explicit and the answer can be checked.

There is one reason it is safe to hand over the privilege. If it breaks, you reinstall and start again. But a reinstall restores only the operating system. Two decisions make the configuration and the data restorable too.

• Every configuration the AI makes is written to files and committed to git. A reinstalled machine gets the same configuration back from git
• The data is copied off the machine every day (next section)

With these, a reinstall brings the machine back as it was. So the human keeps only what even that cannot restore, which is the next section.

The human keeps only what a reinstall cannot restore

• Keys and accounts — domain registration and the management of contracts and payment never live on this machine. What lives here is the AI's own login and the secrets the services need to run
• Actions taken outside it — changing DNS, sending mail, deleting data in an external service. The AI states these before doing them, and a person approves
• Copies of the data — databases, files, mail, and repositories are copied off the machine every day. The copy is pulled from outside, so root on this machine cannot delete it (2-01: "protect only the data and the spec")

Everything other than these three can be left to the AI.

Separate the public side from the AI's side

• At this chapter, the only ports open to the outside are 80, 443, and ssh. Other ports are opened in the chapter that needs them (mail in 2-08, for one). Opening a port is an action the AI states before doing
• The desktop connection is not exposed; tunnel it from your own PC through ssh
• The public website and the AI's work run as different users. Each service, too, runs as its own user with systemd's restrictions
• ssh is keys only; password and root logins are turned off
• Security updates are applied automatically (unattended-upgrades)
• Logins, one-time codes, and intake endpoints get an attempt limit (fail2ban, or in the app)
• Dependencies are installed at pinned versions (uv.lock in git; 2-10)

The point is that a hole on the public side must not reach the data and keys on the AI's side. What 2-05 says, *central minimal and defense in depth at every server*, does not change because there is only one machine.

Run more than one AI, and have them watch each other

Do not run a single AI. Add one from another vendor. Not depending on one vendor is the same reasoning as avoiding the lock-in examined in 3-05.

Then have them check each other. Pair AIs from different vendors, and give the checking side only the artifact and the criteria. Do not give it the history of how the thing was built. An AI that shares your reasoning shares your blind spots.

What you need

• One PC, left powered on
• A connection reachable from outside. Point a name at it with a fixed IP or DDNS (2-11). Handling mail needs a fixed IP and reverse DNS (PTR) (2-08)
• The AI subscriptions

Memory and disk sizes are not set here. Tell the AI what this series stands up, and it decides whether the PC at hand is enough and what to add.

The server can be cheap hardware. If it breaks, replace it. No dedicated server machine, no maintenance contract.

Reverse DNS (PTR) is the record that looks up a name from an IP address — the opposite direction from ordinary DNS, which looks up an IP from a name. A receiving mail server takes the IP of the machine that sent to it, looks it up in reverse, and checks that the name it gets resolves back to the same IP. If it does not, the mail is treated as spam or refused. Gmail requires this of every sending machine (Google's email sender guidelines, checked 2026-10-05).

The reverse record is set by the owner of the IP address, the line provider. On a fixed-IP line it is normally already in place, so there is nothing for you to do.

What it costs

At list prices on 2026-10-05 (excluding tax, billed monthly), Claude Pro is $20 a month and Claude Max starts at $100. Another vendor's base plan sits in the same range (ChatGPT Plus is ¥3,000 a month on the Japanese pricing page). Two are listed because you subscribe with two vendors, so they can check each other.

In operation the AI's work is confirming things run and making small fixes. You are not having it write all day, so the base plans are enough.

No approval process, no server contract, no per-seat licenses. Only the person who builds talks to the AI, and the subscription is that one person's. Letting others use a personal account is forbidden by the terms (Anthropic's Consumer Terms). What the whole group uses is the tools the AI built, and those need no seat per head.

How to check you are done

This chapter is done when these six hold.

1. You can ssh into the server from your own PC
2. You can connect to the desktop from your own PC through ssh and see GNOME
3. systemctl --failed lists no failed service
4. Seen from outside, nothing but 80, 443, and ssh is open
5. The AI's configuration is in git, and the copy of the data has arrived off the machine
6. Asking the AI to report the state of this machine produces a report

ssh builder@example.com     # 1
systemctl --failed          # 3
sudo ss -tlnp               # 4 — list the listening ports

What the human holds

Values the human supplies

• The server's domain name
• The ssh public key of the human's own PC
• The name of the first administrator
• The place off the machine where the data copies go

Actions the AI states before performing

• Changing a DNS record
• Opening a new port in the firewall
• Sending mail to the outside
• Deleting data in an external service
• Reinstalling the operating system
• Deleting a data copy kept off the machine

Versions checked, and when

• Debian 13 (trixie), GNOME 48
• Claude's and ChatGPT's prices were checked on 2026-10-05
• This procedure was written on 2026-09-20 and reviewed on 2026-10-05
• If a version has moved, have the AI confirm the official procedure before proceeding

Summary

Decide the machine the Independence part runs on, first.

• One machine for all of it — public website, in-house tools, the AI's own work; only the self-hosted LLM goes on a separate server
• Debian as the OS — Python and apt from the start, no reboots on someone else's schedule
• No Docker — a tool for distributing, not for building. Install with apt, run under systemd. The only exception is software shipped only as a container, and you never build an image yourself
• Install the desktop too — open documents, look at pages
• Root to the AI — configuration in git, data copied off the machine, so a reinstall restores it
• Three things the human holds — keys and accounts, outside actions, copies of the data
• More than one AI — pair vendors and pass only the artifact and the criteria
• Cost — about $120 a month while building, about $40 in operation (as of 2026-10-05, excluding tax)

The next chapter lays the foundation (SQLite, PostgreSQL, DuckDB) on this machine.

Related articles

• 2-01: Becoming Independent from Microsoft and Google — The Whole Map
• 2-03: Lay the Foundation — SQLite, PostgreSQL, pgvector, DuckDB, Polars
• 3-05: The Lock-In Problem
• Learning Debian with Claude — migrating to Debian, in dialogue