Status

Where the build actually is, as opposed to where the documentation says it should be. Updated as things change; last revised 28 July 2026.

The honest summary: one machine out of roughly two dozen is doing real work. The design is far ahead of the deployment, which is a problem this project is aware of and writing about rather than hiding.

Live

The US gateway VPS — tier 1, the public edge. Running and carrying real traffic:

ComponentState
Hardened SSH (key-only, non-default port)Live, verified
Firewall rulesetLive, verified across reboots
Caddy with real Let’s Encrypt certificatesLive, via DNS challenge
Edge intrusion detection and blockingLive, verified
Dynamic home-address tracking for tunnel rulesLive, verified
WireGuard (server side)Live, no peers enrolled yet
Mesh coordination serviceLive
Notification serviceLive
Uptime monitoringLive

That last group went in on 28 July and matters more than it looks: the mesh coordinator is a prerequisite for any VM joining the private network, so its being live unblocks the entire VM tier.

In progress

  • The tunnel back to home. Blocked on the home-side gateway VM, which cannot exist until there is a hypervisor to run it on. Three defects are already known in that runbook section, found by reading rather than by running.
  • A real fully-qualified name for the mail server. The gateway’s hostname was set correctly, but the change left it without a proper domain-qualified name. Nothing currently cares. The mail server will, so it needs deciding before that runbook starts.

Not started

  • The standby gateway in Europe. Its runbook is written and carries every correction learned on the primary. Nothing has been provisioned.
  • All physical hardware. The hypervisors, the storage tier, and the witness node are specified in detail and not yet racked. The architecture describes an intended end state, not a room.
  • Every service VM. Sixteen of them, zero built.

Proven on test hardware, not yet in production

Not deployed, but no longer theoretical. The automation for the VM baseline, log shipping, and the security monitoring stack has been executed against throwaway virtual machines and verified on the running result rather than from the automation’s own self-report.

That distinction earned its keep. Running the code found defects that four separate document reviews had missed entirely — including one case where the stated mitigation for a known vulnerability did not actually hold, and several where a verification step was structurally incapable of failing.

The gap, stated plainly

Roughly forty runbooks exist. Eight sections of one of them have been fully executed on a real host.

Every review pass, every new design document, and every good idea added to the backlog widens that gap. The gap — not any missing feature — is the actual risk to this project.

There is now a rule about it: new ideas get one paragraph in a backlog file and nothing else until the current tier is running. An idea earns its way out only if deferring it would make some decision expensive to reverse later. Two have qualified so far, and neither was a feature — both were addressing decisions that become costly once hardware is physically installed.

What comes next

  1. Finish the remaining sections of the primary gateway runbook.
  2. Rack and configure the hypervisor cluster and storage.
  3. Build the home-side gateway VM and complete the tunnel.
  4. Identity tier — because nothing above it can be built first.

Progress against this list is what the status updates cover.


Full component inventory

Everything in the design, with an honest status against each. The three values mean specific things:

  • Complete — deployed and verified on the running system, not inferred from a config file. This site has written at length about why that distinction matters.
  • In progress — partially deployed, or proven on throwaway test hardware but not yet running anywhere permanent.
  • Not started — designed and documented, nothing built.

Note how much sits in the third column. That gap is the point.

Public edge

ComponentPurposeStatus
Hardened SSHKey-only remote accessComplete
nftables firewallPacket filtering, survives rebootComplete
CaddyReverse proxy, TLS terminationComplete
Let’s Encrypt via DNS challengeReal certificates, including internal-only namesComplete
CrowdSecEdge intrusion detection and blockingComplete
Dynamic egress-IP trackingKeeps tunnel rules following a changing home IPComplete
HeadscaleMesh VPN coordinationComplete
ntfyPush notifications for alertsComplete
Uptime KumaExternal availability monitoringComplete
WireGuardVPN — server deployed, no peers enrolledIn progress
Rathole tunnelInbound relay to the home networkNot started
Standby gateway (EU)Failover targetNot started
DNS failover automationHealth-checked cutover, ~90s recoveryNot started

Core infrastructure

ComponentPurposeStatus
VM baseline automationCommon build for every VM — proven on test hardware onlyIn progress
Proxmox clusterTwo-node hypervisor with HANot started
Quorum witnessThird vote, breaks cluster tiesNot started
ZFS integrity tierChecksummed storage for small, precious dataNot started
BTRFS bulk tierCapacity storage for media and modelsNot started
UnboundInternal DNS, redundant pairNot started
Home-side gateway VMTerminates the tunnel inside the networkNot started

Identity and secrets

ComponentPurposeStatus
AuthentikSingle sign-on for every serviceNot started
VaultwardenShared and machine secretsNot started

Files and productivity

ComponentPurposeStatus
NextcloudFile sync and sharingNot started
OutlineNotes and internal wikiNot started
LinkwardenBookmark archiveNot started
SnappymailWebmail clientNot started
Paperless-ngxDocument scanning, OCR, archiveNot started
Firefly IIIPersonal financeNot started
n8nWorkflow automationNot started
FreshRSSNews readerNot started

Mail

ComponentPurposeStatus
StalwartMail serverNot started
rspamd + ClamAVSpam and malware filteringNot started
Mail backup and archive pipelineLong-term retentionNot started

Media

ComponentPurposeStatus
ImmichPhoto library with local MLNot started
JellyfinMedia streamingNot started
AudiobookshelfAudiobooks and podcastsNot started
Curated photo sharingSecond, public-facing photo instanceNot started

Communications

ComponentPurposeStatus
FreePBX / AsteriskPhone systemNot started
SMS bridgeMessaging integrationNot started
LAN-only SMS alert gatewayCritical alerts that survive an internet outageNot started
SMS query gatewayConversational status queriesNot started

Development

ComponentPurposeStatus
ForgejoGit hostingNot started
Woodpecker CIBuild automation on an isolated VLANNot started
ZotContainer registryNot started
Dependency-TrackSBOM and vulnerability trackingNot started
Syft + GrypeSBOM generation and scanningNot started
devpi / VerdaccioPackage proxiesNot started

AI

ComponentPurposeStatus
OllamaLocal language model runtimeNot started
Open WebUIChat interfaceNot started
LLM gatewayComplexity-tiered routing, per-service keysNot started
Voice pipelineLocal speech-to-text and text-to-speechNot started
GPU tierCard not yet selectedNot started

Observability and security

ComponentPurposeStatus
Loki + AlloyLog aggregation — proven on test hardware onlyIn progress
WazuhSecurity monitoring — proven on test hardware onlyIn progress
PrometheusMetrics collectionNot started
GrafanaDashboards and alertingNot started
Blackbox exporterCertificate expiry and endpoint checksNot started
Disk and hardware health monitoringPhysical-layer alertingNot started

Operations

ComponentPurposeStatus
Ansible automationConfiguration managementIn progress
Offsite backup chainEncrypted, offsite copiesNot started
Restore proceduresTested restores, not just backupsNot started
Maintenance playbookPatching and routine operationsNot started

Nine components complete. Five in progress. Forty-eight not started.

Every one of those forty-eight has a written runbook behind it. None of that counts for anything until it runs, which is the recurring theme here and the subject of the first post.