How we host the sites we build, and why we do it ourselves

Building a site and then handing it to whichever shared host the client already had is common practice. We stopped doing it, because the site's speed and security after launch then depended on a server we could not see.

One server, many sites, no shared state

Each site runs as its own service on its own port, with its own database role and its own folder. It cannot read another site's files, connect to another site's database or see its settings. The convention is dull and strict, and it is what lets us host client work next to our own with a clear conscience.

Cloudflare in front, nothing else exposed

The origin accepts traffic only from Cloudflare. A request that arrives any other way — including one that guesses the server's address — is refused before any application code runs. Cloudflare terminates TLS at the edge, caches static assets close to visitors in the Gulf, and absorbs the traffic floods that would otherwise reach the server.

Security headers by default

Every response carries a Content-Security-Policy with a per-request nonce, HSTS, a frame-ancestors rule and the rest. They are not bolted on at the end; the templates ship with them, and a third-party script that cannot satisfy the policy does not go on the site.

Updates and backups

Runtimes and dependencies are patched on a schedule, and a package with a known vulnerability is replaced before a release rather than noted for later. The database is dumped every day and the last thirty days are kept; uploaded files are copied on the same schedule, to a location a deployment cannot overwrite.

What it costs the client

A monthly hosting fee that covers monitoring, patching and the backups, and one point of contact when something breaks. What they give up is the ability to move the site to a cheaper host with a control panel. What they get is knowing exactly who is responsible for it.