The estate is the dozen services on a few boxes at home, one small box outside, and the wiring between them. The two earlier posts in this section are about monitoring and about a house that can explain itself. This piece is the long view: what the estate was supposed to become, what each step measured, where it stands in October 2026, and which shapes were kept. The person running it is the playtester, as in the rest of this series.
The goal
The first goal, written on 25 August 2026, was defensive: a repository for the files that existed in exactly one place. A reverse-proxy configuration on a media server, a tailnet policy, a dashboard layout, a printer’s settings, each editable by hand and each unrecoverable if the disk under it died. Capturing them was the first commit, and it immediately exposed the second goal, because a captured file drifts the moment the app that owns it writes a new one.
So the goal became the one the repository carries today: the estate is reproducible from the repository, and a new machine joins it through one ticket. A box that can be destroyed and rebuilt from code is one whose configuration cannot drift silently, and a house whose state is readable by the assistant and by its family is one that can explain itself when something is wrong.
What we tested, and what it cost
The outside box. Over three evenings, 27 to 29 August, a two-gigabyte virtual machine in a nearby city went from nothing to the estate’s outside box, built from code in two layers: an infrastructure tool for the instance, firewall and DNS record, and a first-boot configuration for the user, keys, hardening and unattended security updates. It was rebuilt four times before it was right, and each rebuild was a lesson. A setting that disables root login was overridden by the provider’s own key injection and reported success anyway. A package-selection key in the wrong place was silently ignored. A bootloader update failed on a disk with no partition table, which left the package system half-configured, which would have disabled the unattended updates that were the whole point. The check that would have caught all three was to render the configuration and ask the first-boot tool to validate it before applying. A boring long-term-support distribution won over the rolling release the playtester uses daily, because this box has to work when the house does not.
The control plane moves out. On 28 August the tailnet’s control plane moved from inside the house to the outside box, and every device reconnected with its original key. It was undramatic for a reason decided years earlier: the server address was a name, not an IP, so moving the database and repointing the name was the whole migration. The box then gained an external uptime checker, push notifications, a password vault and a git mirror. Its first lesson about monitoring, that the bot had been down five days while every dashboard stayed green, has its own piece.
One origin. On 18 September every repository moved to a self-hosted forge: ten converted from mirrors, four created, every checkout on both workstations repointed, and the same afternoon the bare git hub that had served as origin was retired. The forge pushes its own mirrors over SSH with a key it generates per mirror, so the outside box needed no second forge, no web endpoint and no reach into the house, which replaced a worse plan. Two traps were caught: a mirror behind its source would have force-pushed the public copy backwards, and a webhook setting that cannot be changed after the hook is created.
Sign-in and the family view. A single sign-on service became the estate’s login in mid-September and moved into its own container on the 19th. Its design is two umbrella groups and three ways an application can sit behind it, and a sign-in page in the house’s own skin. A dashboard fork gave the family one line that says whether the house is fine, then the things they came for.
Fewer copies. The backup review in October counted six copies of some data and the playtester’s direction was that six is too many. Retention is being trimmed and a dedicated backup server, prepared but not installed, is the track back to one proper scheme. The same review chose one self-hosted object store for everything, two terabytes on the big disk, with private blobs encrypted by the client, and dropped a plan to move the chat server’s media into it in favour of migrating the chat server itself.
Where we are
The house is one physical server in a cupboard running containers and virtual machines, the outside box, two workstations, and the tailnet that makes any device on it in-network. The repository describes the outside box completely and most of the inside; a documentation audit this month opened pull requests on every estate repository to say, in the same words, what is deployed, what is merged and what is only coded. A sign-in service is coded and running and not yet in front of every door. The deploy view shows the stages of the last deploy, what must merge first and the open verdicts.
Two incidents this month shaped the next steps. The forge’s container image rotted a layer and began refusing writes; disks and filesystems checked clean, which pointed at non-error-correcting memory and a memory test. And the media server’s init wedged and needed a hard reset, after which its proxy did not start on its own.
By 21 October every pull request from that audit had merged. The first step of putting the sign-in in front of the family’s doors is merged too: the family login flow and the comic studio’s place behind the sign-in proxy are now in the repository, waiting to be applied.
What is next
Run the memory test. Stand up the object store from the playbooks. Migrate the chat server to its lighter successor, with bridges rebuilt fresh and the sign-in service first. Install the backup server and retire the extra copies. Put the sign-in in front of the family site and the comic. Move services off the media VM onto a second edge container. The hardware wishlist, a faster processor, more memory and a small GPU for a local-model worker, stays a wishlist until something forces it. Everything the estate hosts is described in the other journeys; the architecture journey draws the whole.
Architectures we tried
Kept: infrastructure and first-boot as code for anything outside the house; a name, never an address, for anything that might move; one forge as the only origin, with mirrors it pushes itself; the tailnet as the network boundary; a sign-in service with groups rather than per-app accounts. Dropped: a bare git hub as origin; a second forge on the outside box; a configuration-management tool for one box running five containers, which the compose files already describe; six copies of the same data. Pending a decision: configuration management for the inside boxes, which have none, and a reserved address for the outside box, which DNS-from-code made unnecessary so far.