Static Is a Feature

This website has no server. There is no database, no CMS, no login, and no application running somewhere, waiting for a request. It is a folder of HTML files, stored in a private bucket and served through a CDN. That was not a compromise. It was the design.

What the architecture looks like

Markdown → git push → GitHub Actions → Astro build → S3 → CloudFront → zhiyu.si

I write in Markdown and commit. A pipeline builds the site, copies the result to storage, and refreshes the CDN, which serves it. That is the entire system, and publishing an article takes about a minute from git push to the page being live.

What I don’t have to think about

Every component you add to a system is a component you have to operate. A database needs backups, upgrades, and connection limits. An application server needs patching, scaling, monitoring, and someone to wake up when it stops. A CMS needs accounts, permissions, plugins, and security updates — usually for features you never use.

A static site needs none of that. There is nothing to patch at 2 a.m., no process to crash, and no query to slow down under load. Traffic spikes are the CDN’s problem, and the CDN was built for exactly that. The whole thing costs less than a dollar a month.

Simplicity is not the absence of engineering

It is easy to mistake a simple system for an unsophisticated one. Usually the opposite is true: simple systems are the result of decisions, and most of those decisions are about what not to build.

The bucket is private, and only the CDN can read it. HTTPS is handled by a managed certificate. Deployments are triggered by Git and use short-lived credentials rather than keys sitting in a settings page. The infrastructure is defined in code, so it can be recreated, reviewed, and reasoned about. None of this is complicated, but none of it is accidental either.

When static is the wrong answer

Static is not a religion. If something needs to know who you are, change in real time, or accept input from users, it needs something dynamic behind it. Comments, accounts, search across thousands of documents, and personalised feeds are real needs, and pretending otherwise is its own kind of over-engineering.

The point is not that dynamic systems are bad. The point is that complexity should be earned — added when a real need arrives, not because a framework makes it easy or because a future need might appear.

The question I try to ask

Before adding anything — to a website, a product, or a company — I try to ask one question:

What is the simplest thing that fully solves the problem?

Not the simplest thing that half-solves it, and not the most impressive thing that could solve it. The simplest thing that fully solves it. For a place meant to hold writing for many years, the answer is a folder of files — and I think that is a feature.