Under the desk¶

Before the move, the workstation was where text or code got typed and not much else. The build ran locally or at the host, keys were registered in accounts, and recovery meant a mailbox and a phone. This is the part people forget while drawing beautiful diagrams of the cloud. The local machine is where the escape routes live. It holds the keys, the repositories, the build tools, the recovery material, the backups, and occasionally the one working copy of a configuration nobody remembered to put anywhere else. For a one-woman company, local control is the difference between a provider outage being an annoying afternoon and being a small personal apocalypse.

What it holds¶

Purple Lantern is run from one Linux workstation. Sorting what is on it produced a split: the software needed to run the computer, and the software needed to administer the stack. The second set is the one that has to be present locally, and it is short: a browser, Git, SSH, the password manager, the backup tools, and the build tools for the two sites built at home. A machine running from locally available packages keeps working when a SaaS provider disappears; a machine whose essential tools exist only through a commercial account does not.

The browser turned out to be part of the control plane. It reaches the registrar, DNS, mail, the forge, hosting, banking, tax services, monitoring and every recovery portal, which makes browser state more important than it looks: vendor, synchronisation account, saved passwords, passkeys, extensions, certificates, bookmarks. Browser synchronisation is convenient, and it turns the browser into another cloud account holding the keys to several others. So the profile is managed locally, with credentials that recover independently of it, and an extension that handles passwords or authentication counts as infrastructure.

The vault¶

The password manager sits underneath almost everything. Without care the chain becomes registrar, email, password reset, password manager, cloud account, at which point losing the password manager is an efficient way of losing the stack. The vault is a KeePassXC file under its owner’s control, not behind a hosted identity, and it is backed up with everything else. The questions that were asked of it apply to a cloud manager just as well: does the vault export, does it open without the vendor, where is the encryption controlled, where are the recovery credentials, does the manager itself depend on another cloud identity, and is there an offline copy. Portability is non-negotiable here if it is non-negotiable anywhere.

Git and SSH¶

Git is the local escape hatch for the development layer. A complete clone holds source, history, branches, tags and configuration, so the local client carries more weight than any forge interface. Local Git is the authority, pushed to CodeFloe for the sites and to Codeberg for the labs, with the local clones as the mirror of both and the old copies on GitHub and GitLab left where they were. A forge can disappear without taking the source, and Git itself needs no account with anyone to inspect or manipulate a repository.

SSH reaches repositories, servers, deployment and remote shells, and its assets are local: private and public keys, the configuration, known hosts, the agent, passphrases. The configuration is backed up, with one key per remote. A lost private key is annoying; a lost key plus an undocumented list of which key belongs to which service is archaeology. Per-host configuration lets several providers coexist without one identity, and it makes migration a matter of changing a hostname when credentials and repository settings are already kept apart.

Commits are not signed, so there is no signing key on this machine to look after. If there were, it would belong to the workstation and not to a forge: stored independently, passphrase-protected, with recovery material, the public key published somewhere independent and revocation documented. A forge may display a public key; it does not own the private one.

Backups¶

Backup is where the architecture stops being theoretical. It has three parts, data, software and destination, and all three are dependencies. The software has to restore without its original cloud service, the destination has to be reachable without the machine being backed up, and the format has to stay usable. A backup that exists only as objects in a vendor’s proprietary system is not a recoverable copy.

What gets backed up is the control plane, not only the photographs: the repositories, the SSH configuration, the password vault, the site sources, the build configuration, the DNS records, the domain information, the infrastructure notes, the recovery codes, the mail archive and the accounting records.

The destination has its own graph. A USB disk is simple. A cloud backup is laptop, backup service, provider, storage, identity. Neither is better on its own; a local encrypted copy gives physical control and a remote encrypted copy survives local loss, and using both means losing one does not lose the other. A backup on the same desk survives a failed SSD and not a fire. A backup in the same provider account as the source survives accidental deletion and not the loss of the account.

Disk, key, resolver, VPN¶

Full-disk encryption, LUKS on Linux, protects the control plane from physical compromise, and it brings a paradox: an unencrypted machine is recoverable by anyone who gets the disk, and an encrypted machine with no recovery procedure is recoverable by nobody. The recovery material is part of the backup plan.

A hardware key would move authentication outside the software dependency graph, on every account that accepts one, and not every provider does. The shape is account, then physical key, not account, cloud account, email, another cloud account. There is no key yet. A European-made one is on the list, and when it arrives there will be two, the second as the recovery device, and both written down, because a key nobody remembers registering is no help in a crisis.

The machine has to resolve the forge, the package repositories, the bank, mail, hosting, the CA and the monitoring service, so the resolver is a dependency too. The ISP’s, a VPN’s, or a public one; the aim is that no single resolver becomes a mysterious point of failure, and that for troubleshooting a name can be queried by more than one path. A VPN changes the network path and adds a provider. If SSH, DNS, banking or administration works only through one VPN, that provider is part of the control plane, so the VPN stays an optional path and never the only route to anything critical.

Packages¶

The operating system and the development environment usually depend on other repositories: Debian’s, PyPI, npm, vendor repositories, etc. Some are European, some US, some global community infrastructure with no useful national identity. Being able to install a package and being able to reproduce the environment if the package disappears are different things. The package manager is local; the packages are not, and a build that works on Tuesday can fail on Friday because a package moved, a repository changed or a signing key expired. Pinning and local caches belong to the workstation as much as to the build layer, so that the machine keeps enough to reconstruct what worked.

Tree¶

                  ┌── password vault
                  ├── SSH keys
                  ├── Git repositories
   workstation ───┼── build tools
                  ├── DNS configuration
                  ├── recovery material
                  └── backup tools
                            │
                   independent backups

A locally controlled operating system with the administration tools present, an encrypted disk and an encrypted vault, local repositories and a portable SSH configuration, a reproducible build environment for the two sites built at home, independent backups with the recovery written down, more than one route to critical services, package dependencies recorded, the VPN optional and name resolution not on one provider. Not a miniature datacentre. A laptop that stays useful when the datacentre, forge, registrar, mail provider or payment service has a bad day.

The local control plane has one property the cloud layers lack: a provider can be sanctioned without reaching inside a machine on a desk. If a host closes the account and the machine still has the repositories, the build environment, the DNS credentials, the SSH keys, the vault, the recovery keys and the built artefacts, the host has caused an outage and has not taken possession of the stack. The exception is the recovery chain: if account recovery runs through an email provider that runs through a US service, the machine may hold the keys and be unable to use them. Local copies of credentials and recovery material are what break those loops.

The Internet is off, what now? The machine can still open the vault, inspect the repositories and the SSH configuration, build the two sites whose dependencies are local, inspect the DNS configuration, read the recovery instructions, reach the local backups, produce the artefacts already built, and say what has become inaccessible instead of failing mysteriously. Then one provider goes, then the mail account, then the forge, then the host, and each time the same question: can the machine still administer, find the recovery material, build, and publish? The local control plane does not prevent dependency. It decides whether dependency has become captivity.

Granny Weatherwax’s broomstick will not start without somebody running alongside it, and she keeps it anyway. It is hers, and it goes where she points it.