Static sites for public institutions: fast, cheap, hard to hack
Why we default to static generation for public content, and what it does to hosting bills and attack surface.
Most government and institutional websites don’t need a server. They need a stack of pre-rendered pages, a content workflow, and a hosting bill nobody has to think about. We default to static generation for almost every public-facing site we build, and the reasons have very little to do with what’s fashionable in web development this year.
The attack surface argument
A dynamic website with a database, an application server, and an admin panel gives an attacker three things to go after. A static site compiled ahead of time and served as flat files has one: the files themselves, and those don’t execute anything. We’ve inherited institutional sites where the previous vendor’s CMS hadn’t been patched in two years, because patching meant downtime nobody wanted to schedule. Static generation removes that whole category of risk by removing the thing that needed patching.
What it does to the hosting bill
A static site served from a CDN edge network costs a fraction of what a database-backed application costs to run at the same traffic, because there’s no compute per request, no database connection pool to size, and no autoscaling policy to get wrong during a spike. For public institutions whose budgets are approved a year in advance and audited afterward, a hosting bill that doesn’t move month to month is not a minor convenience. It’s one less unpredictable line item to defend.
FIELD NOTE We migrated a ministry-affiliated site off a legacy CMS that had gone down twice during high-traffic announcement periods, the exact moments its uptime mattered most. The static rebuild has had zero unplanned downtime since.
Where static stops being the right answer
Static isn’t a religion. The moment a site needs real-time data, user accounts, or a workflow that changes state per visitor, you need an application, and pretending otherwise produces worse engineering than just building the application properly. The judgment call is knowing which parts of a platform are genuinely dynamic and which parts are content that changes on a publishing cadence, not a per-request basis. Most institutional websites, once you look honestly at what actually needs to be live, turn out to be almost entirely the latter.
This site is one of them. If yours might be too, that’s usually the first conversation worth having, before anyone talks about frameworks.