← Back to blog

This Site's Agent-Friendly Static Stack

April 28, 2026

I wanted a simple place to write things without over-engineering it. No database, no CMS, no server to maintain. Just files, a build step, and an S3 bucket. Here’s the stack today:

• Typora as CMS, to write blog content as markdown
• Astro for static page generation
• GitHub and GitHub Actions as version control and deployment
• S3 and Cloudflare for hosting and routing

Working with Astro

Astro is a static site framework that’s great for content-heavy sites. It outputs plain HTML, CSS, and JS. No runtime or server. The whole thing is a folder of files I sync to S3.

Blog posts (including this one) are Markdown files sitting in src/content/blog/. Astro picks them up via content collections, renders them at build time, and spits out a static page for each one.

Writing a Post

Adding a post is as simple as creating a new .md file:

src/content/blog/my-new-post.md

The file needs a frontmatter block at the top:

---
title: My New Post
description: One sentence about what this covers.
publishDate: 2026-05-01
---

Your content goes here in plain Markdown.

That’s it. The filename becomes the URL slug. Commit it, push it, and it’s live.

The Deploy Pipeline

Every push to the repo triggers a GitHub Actions workflow. Here’s what it does:

1. Checkout the code
2. Install dependencies with npm ci
3. Compute deployment settings — figures out whether this is a production push or a branch preview
4. Build the site with npm run build (Astro compiles everything to a dist/ folder)
5. Configure AWS credentials using repository secrets
6. Sync dist/ to S3 using aws s3 sync

If you’re pushing to master, the site goes straight to the root of the S3 bucket — that’s production. If you’re on any other branch, it deploys to a prefix: previews/<branch-name>/. So every branch gets its own live preview URL automatically. This is great for website edits, especially having Copilot/Claude make a change from my phone, and being able to preview it a short while later.

For pull requests, the workflow also posts a comment with the preview URL directly on the PR.

S3 Hosting

The S3 bucket is set up for static website hosting. The workflow uses aws s3 sync dist/ s3://bucket-name --delete — the --delete flag cleans up any files that were removed in the build, so the bucket stays in sync with whatever’s in dist/.

AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, and AWS_S3_BUCKET) are stored as repository secrets. The workflow pulls them in at runtime. Never store secrets in your code!

Continuous Deployment

The practical effect of all this: I merge a PR, and within a couple minutes the site is updated. I never touch a server or manually upload anything.

That loop matters to me. Edits and writing should be low-friction. If publishing required more than a commit, I’d write less.

Using Agents to Update It

Worth reiterating, I can use GitHub Copilot’s coding agent update the site and edit posts. I open an issue describing what I want, assign it to the agent, and it drafts the changes, commits it to a branch, and opens a PR. I review, tweak if needed, and merge.

Why This Setup Works

• No infra to maintain. S3 is rock solid, and there’s nothing to patch.
• Everything is versioned. Posts are in Git!
• Previews are free. Every branch gets a live URL with zero extra config.
• Fast to write. Markdown in a text editor, commit, done.

Markdown files as database can cover a surprising number of usecases, and I’m sure I’ll pull some of the ideas into new projects. I do plan on reusing this stack for all future static sites to keep things consistent.

Drop a link to this post to your agent, and set one up for yourself.