Astro

Last reviewed Aug 26, 2026 · 883 words

An Astro site in production is a directory of HTML, CSS, and images, served by any web server. The 512 MB of RAM in the catalogue is for the machine that builds it, not the one that serves it; a static Astro blog will serve from a $5 VPS, a Raspberry Pi, or the Caddy instance already fronting your other services, using memory you will struggle to measure. So the self-hosting question is not "can my server run Astro" but "where does npm run build run, and what triggers it". Get that pipeline right and the site is unbreakable in a way no PHP CMS ever will be.

The build is the whole operational surface

npm create astro@latest scaffolds a project; npm run dev serves it on port 4321 with hot reload; npm run build writes the finished site to dist/. Node.js and a few hundred megabytes of node_modules are required for those three commands and for nothing else. That is the "requires Node tooling" con from the catalogue, and it is real: a WordPress author can write from a phone in a hotel, while an Astro author needs a machine with a toolchain, or a pipeline that does the build for them.

The minimal pipeline I run is a Git repo, a build script on the server, and a webhook or cron entry that runs it:

set -e
cd /srv/blog-src
git pull --ff-only
npm ci
npm run build
rsync -a --delete dist/ /srv/blog/

Save that as deploy.sh and run it with sh deploy.sh. rsync --delete into a separate directory means the live site is never half-built; a failed npm run build exits before the copy. Push from a laptop, wait 30 seconds, done. A Forgejo webhook can fire the script on push if you want it automatic, and a CI runner can do the build instead of the web server if you would rather that machine never see Node at all.

Serving it is 5 lines of Caddy

blog.example.com {
    root * /srv/blog
    encode zstd gzip
    file_server
}

Astro writes clean URLs as about/index.html by default, which Caddy's file_server resolves without extra rules. Add a 1-year cache header on /_astro/* if you like: Astro fingerprints every asset filename in that directory, so the cache can be effectively permanent. Everything a Lighthouse audit checks is either already done by Astro or fixed with those cache headers; the Core Web Vitals for static sites post has the header set I use.

Content collections are why it scales past 50 posts

Blog posts live as Markdown or MDX files under src/content/, and a schema declares the frontmatter each post must have. Publish with a missing pubDate or a mistyped tags field and the build fails with a line number rather than a page that renders wrong. At 10 posts that feels like bureaucracy. At 200 it is the difference between a blog you can refactor and one you are afraid to touch. Combine it with the official @astrojs/rss and @astrojs/sitemap integrations and the feed and sitemap generate themselves from the same collection.

Zero JavaScript by default, and you opt back in per component

Astro renders components to static HTML at build time, so a text-heavy blog ships no client-side JavaScript. When a page needs interactivity (a search box, a comment widget, a chart), you mark that one component with a client: directive such as client:visible, and only that component hydrates, in whatever framework it was written in. React, Vue, Svelte, and Solid all work side by side in one project. This is the mechanism behind "excellent performance" in the catalogue's pros, and it is the reason to pick Astro over Hugo when you know you will want a few interactive islands; the Astro versus Hugo comparison goes through the cases where Hugo's single binary and faster builds win instead.

No admin UI is a feature until it isn't

There is no login page, no WYSIWYG editor, and no media library. Writing means editing files, and drafts are a draft: true field that the collection query filters out. For one technical author that is a relief: nothing to patch, no admin panel to brute-force, a Git history of every edit. For a co-author who does not use Git it is a wall. The fix, if you need one, is a Git-backed CMS such as Keystatic that writes Markdown into the repo through a form, which keeps the static build while giving non-technical writers a text box.

What I'd do

Astro with content collections and the rss and sitemap integrations, source in a Git repo, the build script above triggered by a push webhook, dist/ served by the Caddy instance you already run. Put the build on a machine with at least 1 GB free; the server can be anything. Choose Astro over Hugo if you can name an interactive component you will want in the first year, and Hugo if you cannot. Coming from WordPress, budget one weekend for the migration and expect never to run a security update on the blog again.