Personal infrastructure

Fixed-IP Hosting Runbook

How websites get published to the personal AWS Lightsail host, why every hostname resolves to a single IPv4 address, and how two AI agents share the machine without stepping on each other.

Why one fixed IP

The constraint that shapes everything: the intended audience sits behind a corporate firewall that whitelists destinations by IPv4 address, not by domain name. A page is only genuinely reachable if every resource the browser must fetch lands on the same whitelisted address.

So the topology is deliberately old-fashioned — one Lightsail instance, one attached static IP, many hostnames served by Caddy through SNI virtual hosts. No CDN, no proxy, no Cloudflare orange cloud, because each of those would replace the destination IP and silently break the whitelist.

Topology

The publish pipeline

Publishing never touches the web server configuration by hand. The client packages a build; the server validates it independently and installs it.

1. Build and test locally. Static export is preferred whenever the requirements allow it.
2. Preflight. The build root must hold a real index.html. Symlinks, device files, .git, .env*, private keys and package caches are rejected outright, as is any critical asset whose origin does not resolve to the whitelisted IPv4.
3. Package. A UUID-named tarball of regular files and directories only, hashed with SHA-256 locally.
4. Upload. SCP into the deploy account's fixed incoming directory. That account can do nothing else.
5. Invoke the wrapper. A single root-owned helper, static-site-admin, is the only privileged entry point.
6. Server-side re-validation. Owner, size, digest, archive members, slug, mode and destination paths are all re-checked on the server. The client is not trusted.
7. Atomic switch. An immutable release directory is created, current is flipped, the Caddy config is validated, then gracefully reloaded. A global lock serialises this, so two agents publishing at once is safe.
8. Verify, or roll back. DNS, certificate, required paths, same-origin assets, and an anonymous external fetch. Anything fails and the release is rolled back — a successful upload is not a successful publication.

Security boundary

The design assumption is that the publishing client may be wrong or compromised, so privilege is kept off it.

• Uploads run as a non-root codexdeploy account with no standing privileges.
• sudo permits exactly one command — the publish wrapper. Nothing else.
• Hostnames and filesystem paths are derived server-side from a validated DNS-label slug. The client cannot supply a hostname, a path, a fragment of Caddy config, or a shell fragment.
• BatchMode=yes and StrictHostKeyChecking=yes always. Host-key checking is never relaxed to make a deploy succeed.
• Caddy's admin endpoint stays bound to loopback.

The practical consequence: path-based routing such as /some-page under the apex is not available to the publisher, and adding it would mean hand-editing root-owned config. A new subdomain costs nothing instead — the wildcard record already resolves it.

Two agents, one machine

Two AI coding agents publish to this host. The slug namespace is flat and shared, so identical slugs would overwrite each other's sites. That is resolved by reserving a prefix.

Each agent's catalogue enumerates the server directly and filters to its own namespace, so neither library lists the other's sites and neither needs a hand-maintained list. Each agent is also barred from publishing, rolling back or deleting anything in the other's namespace.

Operating notes

• Safe Concurrent publishes — the server serialises them behind a global lock.
• Watch Storage. Every site retains up to five rollback releases; usage is worth a glance before publishing anything media-heavy.
• Watch Public means public. There is no password and no allowlist — anyone with the URL can read the page. Confidential material does not belong here.