For a long time the honest answer to “is everything fine?” was “I think so.” One big machine in a cupboard ran a dozen virtual machines and containers: the media library, the chat server, the family’s game, an assistant bot, a 3D printer’s brain, a code forge, the home-automation system. Each had its own little green light, and the green lights disagreed. A stopped social-network server had been off for weeks before anyone noticed, and the thing that noticed was a page on the far side of the internet going grey. A dashboard that only knows its own box cannot tell you the box is gone.
So the house grew a nervous system, and then it grew opinions about itself. This is what it looks like now: one page that tells each person what they are allowed to know, one way for any change to arrive, one sign-in, one place the backups go and one place they go after that, one record of everything being worked on, and a home-automation system that can turn a lamp yellow when the servers are unhappy.
Who sees what
There is one front door, and it asks who you are. A stranger who lands on the family’s page sees news, markets and the weather, and a button that says Sign in. A family member who signs in sees one more thing first: a single line that says the house is fine, or that it is not, in words rather than percentages. Under it: what the printer is doing and how much filament is left, where the films and audiobooks are, what the assistant is up to, the calendar, and a handful of things from the home-automation system that were chosen by hand. Nothing on that page has a button that changes the house. A friend sees the stranger’s page plus the one game they were invited to play.
The administrator sees the rest: every machine’s memory, every public name and how many requests it answered or refused in the last day, which certificates expire when, when each backup ran and how old its second copy is, what shipped last night and whether the nightly tests passed, and a short list headed Waiting on you. The rule is that the family page says whether, the admin page says why, and the graphing tool, with axes and thirty days of history, says when and how much. The family page draws nothing more than a sparkline; anything with an axis is a link.
One sign-in, two families of people
Signing in is one page for everything, with the house’s own look: a Z drawn in one stroke, mauve fading to peach, with a single yellow point, the light left on. A new person gets an invitation link, makes a passkey on their phone, and from then on the same account opens the dashboard, the audiobooks, the printer console, the forge and the private network.
People belong to one of two umbrella groups, family or friends, and inside each umbrella there are finer groups for the things only some of them need. The two umbrellas start with the same access; the first difference is a group inside friends that opens the board-game site, which the family does not have. Every page reads the umbrella to pick what to show, and an app that needs a finer group asks for it by name.
Not everything can do that dance. Televisions and some phone apps keep their own simple logins, on purpose, because a living room should not depend on the identity server being up. Old services that only understand a username and password sit behind a proxy that does the sign-in for them. And the login that must work when the house is dark, the password vault and the outside watcher, lives outside the house.
How a change reaches the house
Nothing is changed by typing on a server. A change starts as a ticket in the house’s own code forge. An assistant, or a person, does the work on a branch and opens a pull request. Tests run in a throwaway container that cannot see the house. Then exactly one gesture from the owner, on exactly one version of the change, says yes: a label, a word, or a tap on a card in the chat. The assistant merges it.
Deploying is a separate, boring machine. It builds the software from the exact merged commit, pushes the image to the forge’s own registry, and writes down the image’s fingerprint, a long hash that names those bytes and no others. The server is told to run that fingerprint, never “the latest”. Nine checks follow: is it healthy, is it running as the unprivileged user it should, is it listening only where it should, does the front door answer with a 200. If any check fails, the previous fingerprint is put back and the failure is reported in the same chat room where the yes was given. The assistant that merges the changes ships through the same machine as everything else; she does not get a private road. The forge is the only place code lives; there is no second copy of a repository that could quietly disagree with it.
A bot opens a pull request whenever a container image or a pinned version moves upstream, with the changelog attached; the owner reads it and gives the same one gesture; the same machine ships it. Nothing updates itself overnight, least of all the thing that drives a heater.
How it is watched
Every machine reports a few hundred numbers every thirty seconds to one small collector. The web front door reports every request’s name, status and duration. A log shipper sends system journals and a short allow-list of container logs to a log store next to the collector, with passwords and tokens scrubbed before they leave the box. The collector has no login of its own, so nothing reaches it except through a tiny door that only passes read-only queries. The log store has no door at all; it turns its logs into counts, per client and per country, and hands the counts to the collector.
There is one answer to “is it up”: a prober inside the house checks every name, with its list of names kept in git, and the alarm is not in the house. An outside watcher on a rented server checks the public names from the internet and expects a heartbeat from inside; if the house goes dark, the heartbeat stops arriving, and the silence is the signal. That watcher, the private network’s control plane and the password vault are the things that must keep working when the cupboard is unplugged, so they all live outside it.
How it is kept safe
The front door sorts names into three kinds: public with the app’s own login, reachable only from the house and the family’s private network, and public by design. The private ones answer a stranger with a flat refusal; measured over a day, about five hundred of those refusals happen, nearly all from scanners probing names that exist in DNS but have no door. Public names carry a rate limit, and a handful of rules watch them: a tripped limit, a run of failed logins, a backend that starts failing, a sudden flood, a certificate about to expire. All of them are tuned against a day of real traffic so that a normal day is silent. The next layer reads the access log and bans the noisiest clients at the door for a day, with the house and the family’s own devices on a never-ban list; it runs in watch-only mode for its first week, so the owner can see what it would have done before it does anything. Its decisions stay inside the house; nothing outside is asked for permission to refuse a packet.
The private network uses the same sign-in. A person’s phone joins by signing in; the group they belong to becomes a tag, and the tag decides what the device may reach. Family devices reach the house’s web pages, the printer and the exit to the internet; they cannot open a shell, scrape the numbers or reach the hypervisor. A machine joins with a one-hour, single-use key issued from the admin page and shown once as a QR code, and machines are never owned by a person.
The assistants that work on the house get no quieter road either. When one opens a shell on a server, it uses a key of its own, separate from the owner’s. The servers enrolled so far answer that key only through a small recorder. Every command lands in the server’s journal, classed as a read or a write, with the session that sent it. Where that journal reaches the log store, a write pings the owner’s phone. The workstation keeps its own copy of the same line, so the command is tied to its session even on a server that will not pass the session along. The owner’s terminal is untouched: only an assistant’s session offers the recorded key.
How it is backed up
Backups used to mean copying every virtual machine’s whole disk every night, which filled a twenty-terabyte drive with a hundred copies of the same operating system and locked the main server for six hours each morning. Now a backup server on the same box takes a nightly incremental, deduplicated copy of every guest to a second disk, verifies it, and keeps seven days, four weeks and three months. The media libraries are left out, because the films are rebuildable and the drive is not infinite; the family’s photos are kept.
The second copy is the interesting part. It lives on a workstation that normally sits at another site, and it is filled only when that workstation is plugged into the house’s own network. The sync job points at the workstation’s house address and nothing else; when that address does not answer, the job skips and writes down how old the copy is, and the admin page shows the number going up until someone brings the machine home. Carrying the copy over the private network from the other site is possible, but it is an explicit, one-off choice, never the default, because it would spend the house’s bandwidth on something a car can carry. Nothing is backed up to the rented server outside; it is rebuildable from the configuration, and the configuration is code in the forge, mirrored, with every secret kept out as a name that points to a file on the box.
Every one of these facts is a number on the admin page: the age of each guest’s last backup, whether the verify passed, the age of the second copy, and the age of the last restore drill. A number that has not moved in a hundred days turns yellow, because a backup nobody has restored from is a hope, not a backup. The old whole-disk job keeps running beside the new one until two drills have passed; only then does it stop, and only after the owner has seen the exact list, with sizes, of what will be deleted.
One record of all the work
Work on the house happens in many places at once: an assistant’s queue of tasks, lanes of work a person launches from a terminal, a nightly test run on the workstation with the GPU, bots opening pull requests. The record of all of it lives in one place, with the assistant. A lane announces itself when it starts, says which repository and branch it holds, and sends a heartbeat; a lane that goes silent for half an hour shows as stale, and a second lane cannot take a branch the first one has. The nightly tests post their verdict to the same record. Each task records what it cost.
Out of that record comes one list, headed Waiting on you, that holds every pending card, every ticket marked as the owner’s decision, and every lane that is blocked on him, with one count. The chat room shows the cards, the dashboard shows the count and the top three, the admin page shows the whole list. Things that fail, a dead task, a failed build, a failed deploy, enter a triage state with a seven-day timer: the assistant proposes what to do, the owner disposes. The assistant does not take the lanes over; they keep running themselves. She only keeps the book.
The house and the servers, both ways
The home-automation system already knew the house: who is home, the inside and outside temperature, which lights are on, whether the doors are locked, what the printer is doing layer by layer. The servers already knew themselves. For a long time the two did not know each other. Now they meet in one direction, and the other direction is next.
In one direction, the family page has a House card drawn from the home-automation system, through an allow-list the owner wrote by hand. It shows the weather, the temperature in each room, the coffee brewer, the house’s internet link and its speed, and the age of the home system’s own backup. What the list leaves out is longer: no person, no phone, no location, nothing that says whether a room is occupied, no camera, no microphone, no lock, and nothing that is a control rather than a reading. The printer is not on it either. Its numbers come from the printer’s own console, so every number has exactly one source.
All of it comes through a tiny read-only proxy. The proxy holds the one token the home system issued, answers only for entities on the list, and refuses everything else. The token itself is not read-only, because the home system lets any token call any service. That makes the proxy the only thing enforcing the list, so it is the only place the token lives. The dashboard never holds the token, and no page anyone can see has a button that changes the house. The administrator also sees the home system’s own health: pending updates, its automations, and the batteries of the devices that stay put.
In the other direction, which is the next step, the servers appear inside the home-automation system as plain sensors on an Estate card: one word for the house’s health, a count of alarms firing, the count of things waiting on the owner, the last deploy and whether one is running now, last night’s test verdict, the age of the backups and of their second copy, the number of devices on the private network, the number of refusals at the front door in the last hour, whether a worker has gone quiet. At first the home system simply polls the read-only door for them, with the configuration kept in git; when something needs to be pushed rather than polled, a failed deploy, a red test night, a second copy that is two weeks old, a small bridge publishes the same sensors over the home system’s own message bus, where they appear as a device called Estate.
That is what will let the house have opinions. A lamp in the hall turns yellow when the health word is warn and red when it is bad, and goes out when things are fine: the light left on, which is also the yellow point in the sign-in mark. At nine in the morning the kitchen speaker says how many things wait on the owner. A failed deploy becomes a phone notification carrying the rollback line. A second copy older than two weeks becomes a reminder to bring the workstation home. The home system owns the devices, the automations and the wall panel; the dashboard owns the family’s one-glance read; neither gets a token that can change the other.
Where everything lives
Estate services are leaving the big storage virtual machine for a small container of their own, one service at a time, the dashboard first and the front door last, so that the machine that owns the disks is not also the machine that owns the sign-in. Vendor applications, the media servers and the printer console, are described as compose files in git and managed by a tool that reads those files and never holds a key to the forge; it is on a two-week trial with three pass marks, and a named second choice if it fails one. A new worker machine comes up with one command that pulls its dotfiles from the forge, installs its packages from one list, pins every tool to the same version as every other worker, and decrypts its own secrets with a key the owner authorises once. More memory for the box is planned and nothing waits for it.
A green light that cannot see the whole house is a guess with a colour.
Appendix: history
The decided plan behind this page, phased with owners and what waits on the owner, is the private design document “2026-10-05 estate plan, final” (kept in the estate’s own repository, not published). The audit that produced it, with the measurements, every alternative weighed and the decisions, is its working record, “2026-10-05 estate insight plan”. The earlier monitoring story is Monitoring a house the internet cannot reach.