Static and edge hosting explained
If a page does not need to be assembled per visitor, it can be built once and served as files from locations near your users. There is no runtime to patch, no database to compromise and nothing to fall over under load.
- You get
- Files served from a CDN edge, usually with automatic TLS and deploys from a git push
- You do not get
- A server-side runtime, unless you add functions
- Scaling
- Effectively free — a traffic spike is a cache hit
- Attack surface
- Close to none; there is nothing executing on request
What "static" does and does not mean
It means the HTML is produced before the request, not during it. It does not mean the site is simple or unchanging: a static site generator can render thousands of pages from a database, a CMS or a spreadsheet, and rebuild whenever the source changes.
Interactivity still works, because the browser is a runtime. Search, filtering, forms, carts and dashboards can all run client-side against APIs. What is missing is the ability to compute the page itself per visitor — personalised content, authenticated views and anything that depends on request state.
Why it is so hard to knock over
- A cached file served from an edge location has no database to exhaust and no interpreter to exploit.
- Traffic spikes hit the CDN, not an origin. The cost curve is nearly flat where a dynamic site's is a cliff.
- There is no OS of yours to patch, which removes the single largest source of self-inflicted outages.
- Rollback is redeploying a previous build, which is close to instantaneous.
Filling the gaps: functions, forms and APIs
Every static platform now offers small server-side escape hatches — edge or serverless functions — for the handful of things that genuinely need to run per request: a form handler, a webhook receiver, a token exchange, a redirect rule.
Used sparingly this is the best of both arrangements. Used heavily it becomes a distributed application with the debugging characteristics of one, and a long-running process on a VPS would be simpler and cheaper.
The build step is the new failure mode
Nothing serves until a build succeeds, so the build becomes production-critical: a dependency that changes behaviour, an expired API token used at build time, or a generator upgrade can all stop deploys while the live site carries on happily serving the previous version.
Pin your dependencies, keep the build reproducible, and know how to deploy the previous artefact without rebuilding.
When static is the right answer
Documentation, marketing sites, blogs, directories, reference material, landing pages, anything generated from a data source — which is to say, most of the web. If you cannot name the part of your page that must be computed per visitor, you probably do not need a server.