A website is only as reliable as the place it runs. This topic collects how we host the sites we build at tbskit: where each piece lives, how a change gets from a commit to your visitors, what happens when something breaks, and how we keep the running costs boring.
What “the server” means for a modern site
Twenty years ago this topic would be about a physical machine (or a virtual one) with a web server, a database, and a monthly patching ritual. Most of the sites we build today have no server to log into at all. There is still a server side, but it is made of managed services: a build pipeline, a content delivery network, object storage for media, DNS, and TLS.
That shift changes what “operations” means. Instead of keeping a machine alive, we keep a pipeline predictable: same input, same output, every time, with a copy of everything that matters in version control.
Static-first, edge-served
Where a project allows it, we ship static HTML and serve it from an edge network (Cloudflare, in our case). For a marketing site or a content site this is not a compromise — it is an upgrade:
- No application server to patch, restart, or scale. Nothing to crash under load, because there is no process waiting for requests.
- Fast everywhere. The page is already cached close to the visitor instead of being assembled per request on one machine, in one region.
- Cheap to keep online. A site that mostly serves cached files costs a few dollars a month, not a server instance per environment.
Dynamic features still get built — forms, search, comments, checkout — but as small, separate pieces that call a service, rather than as a monolith that must stay up for the whole site to work.
Where each piece lives
Every project gets a short document that answers “what runs where?”, because next year nobody remembers. For our sites it usually looks like this:
Build and hosting
Source in Git, a build on every push, output published to the edge (Cloudflare Pages). The build is the only place where the site is assembled, so there is one path from code to production — no “it works on my machine, deploy that folder manually” steps.
Media and assets
Heavy images live in object storage (Cloudflare R2) behind a custom asset domain, not in the repository and not on the same host as the HTML. The repository stays small, deploys stay fast, and images can be re-cached or replaced without touching the build.
DNS, TLS, and email
DNS, TLS certificates, and redirects are configured declaratively and documented alongside the code. Email is deliberately separated from web hosting: sending mail is a service with its own reputation and logs, not something to bolt onto a website server.
Deployments you can trust — and undo
A deploy should be the least interesting part of the week, so we make it boring on purpose:
- Every change goes through the same pipeline, including “small” copy edits. If it did not go through the pipeline, it is not in production.
- Preview before production. Branches get their own URL, so a client can click through a change before it is published.
- Rollback in one step. Because the previous build is still there, going back is a click or a single command — not a scramble.
- Redirects live with the content. Moved pages get a 301 in the project, so links that Google and other sites already know about keep working.
Caching that respects your team
Caching is where most “it is still showing the old version” complaints come from. Our rules:
- Fingerprinted files are cached forever (
immutable), because a change produces a new filename instead of a new version of an old file. - HTML is cached briefly, so publishing an update is visible in minutes without a purge.
- Media gets a long cache with a stale-while-revalidate window, which keeps repeat visits fast while still refreshing in the background.
- We change filenames instead of purging caches. If an image must change immediately, it is uploaded under a new name and the page is updated to point at it.
The boring parts that keep a site online
- Monitoring and alerts for uptime and for failed builds: if a deploy breaks, we want to know from a notification, not from a customer email.
- Backups with a recovery story. Content, redirects, and configuration live in Git; uploaded media lives in object storage. We test restoring a page from scratch, because a backup you have never restored is a rumour.
- Security headers and HTTPS everywhere, with TLS managed and renewed automatically.
- Secrets stay on the server side. API keys never go into client-side bundles or public repositories; anything that must reach the browser is scoped and rotated.
- Dependencies get patched on a schedule, not only when something breaks.
Costs and scaling without surprises
Two questions decide infrastructure: what does it cost at rest, and what happens on the day traffic spikes? Edge hosting answers both: the idle cost is near zero, and a viral day mostly means more cached responses, not a bigger server.
We also watch the quieter costs — build minutes, image storage, third-party services per project — and record them in the handover notes, so a growing site does not quietly become a growing bill.
What we publish under Server
Articles in this topic go into individual decisions: choosing a host, structuring a deploy pipeline, handling redirects during a migration, caching strategy, submitting forms without a backend, and what is actually worth monitoring on a static site.
If you want a second opinion on how your current site runs — or you are starting something new — tell us about it and we will map out what belongs where.
