← ALL WRITING
Software · Essay

modularThinkin now on Astro and AWS Amplify

simplify... focus on what is important

Andreas2026.07.23 · 4 MIN READ

My blog ran on WordPress and had become a maintenance job: plugin updates, a database to back up, a theme stuck a few versions behind because upgrading broke the layout. I write a handful of posts a year. The upkeep outweighed the writing.

So I moved it to a static setup: Astro for the site, AWS Amplify for hosting. I did it in an afternoon with Claude as a sounding board for the decisions. This is what the move involved and how to do the same.

What Astro is

Astro is a static site generator built around content. You write posts in Markdown, and it builds them into plain HTML at deploy time. No server rendering pages on each request, no database.

Its main trait: it ships almost no JavaScript by default. Most frameworks send JS to the browser whether the page needs it or not. Astro sends none, then lets you add interactive components only where you want them (“islands”). For a blog, that default fits.

Why Astro

Two alternatives, and why I passed:

  • WordPress: the reason I was leaving. A database, a PHP runtime, plugins, and an admin login bots probe all day. Too much surface area and upkeep for static text.
  • Next.js: a server-side application framework. I don’t have an application, I have articles. Running a React server runtime to serve static prose adds complexity I’d never use.

Astro sits between them: content-first, but with a component model available if I later want something interactive. Hugo and Eleventy would also have worked. Astro won because it uses JavaScript and TypeScript, which I already know, so extending it means no new template language.

Where Claude helped

The useful part was the decisions, not the code.

My default for hosting was the full AWS setup: an S3 bucket, CloudFront for the CDN, ACM for certificates, Route 53 for DNS, wired together in Terraform. Claude flagged it as over-engineered for a personal blog and suggested Amplify, which provides the CDN, HTTPS, and a git-push deploy pipeline without the wiring. That was the right call and it saved the afternoon.

Same for other forks: Astro vs Hugo, whether I needed a CMS (I didn’t, the Markdown files are the CMS), where content should live. Each was a short back-and-forth rather than an evening of research.

Ownership

The setup is self-contained:

  • Content is Markdown in a git repo. That is the source of truth.
  • The site is my code.
  • Hosting is my AWS account.

No platform in the middle can change terms, gate the content, or shut down. Git holds the full history. If I left AWS, the same dist folder deploys anywhere that serves static files. Cost for a static blog on Amplify is in the cents-per-month range.

How Amplify deploys it

Amplify is connected to the GitHub repo once. After that, every git push triggers a build: Amplify pulls the repo, runs npm run build, and serves the static output from a global CDN over HTTPS. There is no server to manage. It is the S3 + CloudFront + CI setup, managed for you. You trade some low-level control for a much simpler pipeline.

Setup in about 20 minutes

  1. Scaffold. Run npm create astro@latest my-blog and pick the blog template. Then cd my-blog && npm run dev to see it locally.
  2. Write a post. Posts are Markdown files under src/content/. Copy one, edit the frontmatter and text, save.
  3. Push to GitHub. git init, commit, and push to a new repo. This is your source of truth.
  4. Connect Amplify. In the AWS console, open Amplify, choose “Deploy an app,” and connect the repo. Amplify detects Astro and fills in the build settings (npm run build, output dist). Deploy.
  5. Go live. In a couple of minutes you get a live amplifyapp.com URL on HTTPS. Every push redeploys.
  6. Add a domain. Under Domain management, add your custom domain. With Route 53 it’s a click; otherwise add the records Amplify gives you. It handles the certificate.

Takeaway

The stack is not the point; several would have worked. What changed is the speed of the decisions. The technical steps took minutes. The choices that used to take an evening of research each, WordPress vs Astro, managed vs raw AWS, framework vs static, ran as a short conversation alongside the build.

Thanks for readingSoftwareMore essays
Written by Andreas

Weekly essays on technology, organizations, AI, data, and software — thinking in systems, assembled block by block.

Follow