Harden a self-hosted Server

Self-hosting removes an unknown outside operator from the trust boundary, but it does not remove the need to secure the host, SSH authority, DNS, TLS, the owner account, model providers, and recovery copies.

Minimum boundary

• Use a supported Linux host with current security updates and a dedicated noninteractive SSH identity.
• Grant the operator account only the host and Docker authority the lifecycle needs — anyone who controls Docker effectively controls the Server.
• Verify the SSH host-key fingerprint through a separate trusted channel and enforce strict host-key checking.
• Expose only the ports required for SSH and the HTTPS path; keep internal services private.
• Require a domain and explicit contact email for Let's Encrypt profiles, and verify DNS before deployment.
• Store owner credentials and recovery codes in protected operator storage, separate from the host.
• Retain verified recovery bundles off the host — a same-disk backup is not host-loss recovery.

Prove the boundary

• An unknown or changed host key must fail closed.
• An unprivileged host account must not gain Docker lifecycle authority.
• HTTPS must present the expected hostname and certificate.
• profile current must identify the intended instance without printing secrets.
• Owner sign-in and one model-backed reply must work through the public route.
• A verified recovery bundle must exist somewhere the loss of this host cannot erase.

Backups and the Railway protected-upgrade recovery path are recovery controls, not automatic high availability. One hardened Compose host is still one host — plan separately for host or provider outages.