Drafted by an AI agent (claude-opus-5) from this lab’s own runbooks, deployment log and errata. Reviewed before publication by the site owner. How this site is written →
First status update, so it doubles as a baseline: this is where the lab actually stands on the day this site went up.
The short version — one machine is doing real work. It is the public edge: a rented virtual server that everything else will eventually reach the internet through. It is genuinely finished enough to depend on. Nothing else is running at all.
What went in
The gateway now carries, all verified on the running system rather than taken from a config file:
- Hardened SSH — key-only, non-default port, root login refused. Verified from outside the host, which turned out to matter rather a lot; that is its own post.
- Firewall ruleset, confirmed to survive a reboot rather than merely to load once.
- Real TLS certificates, issued automatically over a DNS challenge.
- Edge intrusion detection, actively blocking.
- Dynamic home-address tracking — the tunnel rules follow a residential IP that changes without warning. Three separate pieces have to be wired together for that to work, and this is the second time this project has learned that a script existing is not the same as a script running.
And, on the day of writing:
- WireGuard, server side, no peers enrolled yet.
- Mesh coordination service.
- Notification service and uptime monitoring.
What this unblocks
The mesh coordinator matters more than it looks. Nothing can join the private network without it — so every virtual machine in the plan was blocked behind this one service existing. That is now cleared.
It is also the point where the ordering pays off: the coordination endpoint has to be reachable from the ordinary internet, because a brand-new device has no mesh connection yet and has to bootstrap over something. Getting that wrong in the other direction — locking it down by network position — would have quietly broken enrolment from anywhere new, and would have looked like a hardening improvement while doing it.
What broke
Nothing catastrophic this round, which is itself unusual. Two things worth recording:
Setting the hostname left the machine without a fully-qualified name. The provider’s default was replaced rather than adapted. Nothing currently cares. The mail server will, so that needs deciding before that runbook starts — logged rather than papered over.
A verification step passed when it should not have been able to. Found while checking something unrelated. That pattern has now appeared enough times in this project to have its own rule, and its own post.
Still not started
Everything else, honestly:
- The standby gateway in Europe. Its runbook is written and carries every correction learned on the primary. Nothing is provisioned.
- The tunnel home — blocked on a gateway VM, which is blocked on a hypervisor, which is blocked on hardware not yet racked.
- All physical hardware.
- All sixteen service virtual machines.
The automation for the base VM build, log shipping and security monitoring has been executed against throwaway machines and verified on the running result, so it is not theoretical. It has simply never touched anything permanent.
Next
Rack the hypervisors and storage. That is the honest blocker for everything above, and no amount of further design will move it.
See Status for the running picture, which is updated as this changes rather than only when a post goes out.