This site is Astro-generated static HTML on Cloudflare Pages. There is no server, no database, no admin login, and no process anywhere that can be up or down. The interesting part is not that it is free. It is that the same subtraction I did here is the one I do to an AI agent before it goes near production traffic: count the things that can be in a bad state, then delete as many as the requirements let me.
The problem, stated properly
The question people ask about infrastructure is “what does this cost per month”. The question that decides whether I sleep is different: how many things can be in a bad state at 3am, and how many of them page me.
Those two numbers usually move together, which is why the cost story gets told. But they are not the same number, and when they disagree, the second one wins. I would happily pay $200 a month for a system with one failure mode over $0 for a system with nine.
For a personal site, the honest requirement list is short. Serve about twenty pages of text. Let me publish from a laptop. Stay up when a post gets shared somewhere large. Nothing on that list needs a running process.
The obvious solution, and why it did not fit
The default is WordPress on a small VPS. I have run that, and I have been the person who got the upgrade notice. It gives you a comment system, a WYSIWYG editor, and plugins, which is a real answer if you need those.
What it also gives you is a list of things that can break independently:
| Moving part | What it can do to me |
|---|---|
| VPS | disk fills, kernel needs patching, provider reboots the host |
| PHP-FPM | version drift, worker exhaustion under a traffic spike |
| MySQL | its own backups, its own restores, its own corruption |
| WordPress core + plugins | security releases on somebody else’s schedule |
| TLS certificate | renews, or does not |
| Backups | untested until the day they are not |
Six things, each with its own failure mode, to publish text. The comment system I would get in exchange is a thing I do not need, because the discussion already happens in the LinkedIn thread.
What is there instead
The whole publish path:
markdown in git
│ npm run build
▼
static HTML in dist/
│ wrangler pages deploy
▼
Cloudflare edge ──► readerReal output from the build that produced the page you are reading:
❯ npm run build
[build] 36 page(s) built in 434ms
[@astrojs/sitemap] `sitemap-index.xml` created at `dist`
[build] Complete!
❯ du -sh dist
1.5M dist1.5MB for the entire site, 368KB of which is self-hosted fonts. The homepage is a 12KB HTML file and a 38KB stylesheet. There is no origin to reach: Cloudflare serves files it already has, so the slowest thing in the request is the reader’s own network.
The failure modes that survive this design are: I write something wrong, or Cloudflare has an incident. I can fix the first. I cannot fix the second on any architecture I could afford, so it is not a real difference.
The same move, applied to an agent
This is the part that matters more than my hosting bill, and it is why the site is built this way rather than some other free way.
An agent demo has one moving part, the model. An agent in production grows them fast: a vector store, a queue, a state table, a retry policy, a tool layer talking to systems that have their own opinions about rate limits. Every one of those is a thing that can be in a bad state while the model itself is fine.
So the first design pass on an agent is subtraction, and it looks like this:
- Does this need retrieval, or does it need three documents in the prompt? Retrieval brings an index, an embedding pipeline, a staleness problem, and a permissions problem. Three documents bring none of those.
- Does this tool call need a queue, or does it need to be idempotent and retried inline? A queue is correct when work must survive a restart. It is overhead when the work takes 200ms.
- Does this need conversation memory, or does the caller already have the context and can pass it? Memory is a database with a consistency story.
Every one I delete is a thing that cannot page me. What is left gets the attention that would otherwise have been spread across all of it. That is the same trade as the table above, on a system where the stakes are somebody’s production data rather than my blog.
The trade-off, honestly
Static is not free of work. It moves the work to build time and to me.
There is no comment system, no search, no email capture without a third party, and no way for anyone who does not use git to fix a typo. Every change is a rebuild and a deploy, so a one-character fix costs the same ceremony as a new post.
And “no server” does not mean “nothing to operate”. Two examples from the last week, both mine:
Cloudflare Pages serves every route with a trailing slash and 301s the bare path. Four of my in-body links were missing that slash, so every click and every crawl was paying a redirect. That is not a bug any monitoring would have caught, because nothing was down.
Worse: a static site with no 404.html makes Pages fall back to SPA mode, and
it starts answering every unknown URL with the homepage and a 200.
❯ curl -so /dev/null -w '%{http_code}\n' https://kazishiplu.com/does-not-exist
200That is a soft 404, and it means an unbounded number of URLs all return the same page. It had been true since I cut over from the old site, and I found it by curling my own domain rather than by getting an alert. Fewer moving parts means fewer things that break loudly. The quiet ones still need somebody to go looking.
What I would tell someone starting
Do not pick static because it is cheap. Pick it because you wrote down what the thing has to do, and nothing on that list needed a process running.
Then do the same exercise on the system you are paid for. Take the architecture diagram and ask, for each box, what happens if this is in a bad state at 3am, and what would I lose if it were not there at all. On a personal site the answer removes a VPS. On an agent it removes the vector store you added because everyone adds one.
The bill going to zero is a side effect. The point is the shorter list.