Before building this site, I had never used Astro.
That made it a questionable choice if the only goal was to launch as quickly as possible. I could have used a hosted blog platform, installed a familiar content-management system, or picked a page builder that hid most of the technical decisions.
Instead, I chose a framework I would have to learn while using it, stored the project in GitHub, and put the public site behind Cloudflare so it would not depend on anything running in my garage.
The stack was not about collecting fashionable tools. Each piece had one job.
What the publication needed
Field Notes is primarily a collection of articles, archives, topic pages, and a few supporting pages. Readers do not need accounts, dashboards, or a large client-side application.
I wanted:
- Markdown-based writing
- Reusable layouts and components
- Categories, tags, archives, series, and RSS
- Fast public pages
- Git-based version history
- Automatic deployment with useful failure logs
- Room to grow without maintaining a traditional public server
The content needed to stay easy to write even if the presentation became more sophisticated later.
One responsibility per layer
The final division looks like this:
| Concern | Tool | Why it fits |
|---|---|---|
| Articles and page generation | Astro | Markdown content with reusable layouts and components |
| Version history and source of truth | GitHub | Every content and code change is reviewable |
| DNS, HTTPS, builds, and public delivery | Cloudflare | The site stays available without depending on my homelab |
That separation makes troubleshooting more direct. A content-schema problem belongs in Astro. A source-history question belongs in GitHub. A failed deployment or DNS issue belongs in Cloudflare.
The boundaries are not perfect, but they are clear enough that I usually know where to start looking.
Why Astro fit the writing
Astro keeps an article separate from the page around it.
The writing lives in Markdown. A shared layout handles the title, dates, reading time, tags, related posts, series navigation, author information, and other repeated pieces. Components handle navigation, metadata, advertising positions, and the footer.
Publishing another article does not require rebuilding the page by hand.
The important part was not a benchmark score. It was having a structure I could understand and maintain without turning a publication into a larger application than it needed to be.
I started with Astro’s official blog starter rather than an empty directory. That solved the blank-page problem while leaving plenty to replace: branding, navigation, layouts, sample content, and assumptions that did not match Field Notes.
The details of turning that starter into this site became a separate implementation story.
Why Cloudflare fit the public side
I enjoy maintaining servers in my homelab, but a public business site should not disappear because I rebooted a host, changed a firewall rule, broke a container stack, or lost power in the garage.
Cloudflare keeps the public site separate from that experimentation. It also puts several things I already needed in one place:
- DNS
- HTTPS at the edge
- Build and deployment logs
- Environment variables
- Global delivery
- A path to use Workers features later
The repository is the source of truth, and Cloudflare rebuilds the site when changes reach the main branch. I cover the operational reasons for staying with Cloudflare in more detail elsewhere.
The free starting point mattered
Eldritch IT is still being built, so I did not want the website stack to collect subscriptions before the business had a reason to pay for them.
Astro is open source, GitHub stores the repository, and Cloudflare’s free tier covers the current deployment. That let me build on the real platform without planning an early migration or adding another recurring bill.
If traffic or requirements eventually justify paid features, there is room to add them. For now, the stack does what the site needs.
The tradeoff: I have to understand the seams
Managed tools remove some maintenance, not all responsibility.
Astro has content collections, adapters, static paths, and a build-time/runtime boundary. Cloudflare has Workers, build settings, bindings, compatibility flags, and environment variables. GitHub sits between them as both history and deployment trigger.
When something fails, the answer is often at a seam between tools rather than inside one of them.
That is the cost of the stack: less infrastructure to operate, but more interfaces to understand.
Key takeaways
- The stack works because Astro, GitHub, and Cloudflare each have a defined responsibility.
- Static-first publishing fits the actual site better than a larger application or database-backed CMS.
- Cloudflare keeps the public site independent from homelab experimentation.
- A low-cost stack is only useful if deployment failures remain visible and understandable.
What I would do differently
I would document the boundary between the three tools before adding features.
A one-page map of where configuration lives—Astro, GitHub, or Cloudflare—would have prevented several rounds of searching. I also would verify the canonical URL, deployment mode, environment-variable names, and draft-exclusion rules before the first public build.
AI transparency
AI helped explain unfamiliar Astro concepts, review code, organize implementation work, and edit this article. I reviewed the changes, resolved deployment problems, and made the final decisions about the site’s architecture, design, and content.