Two Months After Hugo, I Built rabin.blog Again With Astro

Just about two months after moving rabin.blog to Hugo, I decided to build it again. This time with Astro, and a custom design inspired by another blog I liked.

Yes, again. This is the seventh major iteration of this little site.

I can see how that looks from the outside. I had a working blog, wrote about why I chose Hugo, and then changed the engine a couple of months later. But rabin.blog itself is part of how I learn. I experiment with something, use it for a while, and find out what I want to do differently. Sometimes the blog gets caught in the experiment too. 😊

The Astro version went live on 16 October 2026. It took about 18 hours of work, with some elements and logic carried over from the Hugo project.

A little background before another rebuild

Rabin.blog started in 2017 as a smaller place beside my main site, ruhanirabin.com (opens in a new tab). It gave the code, fixes, and small hacks somewhere to live without turning each one into a polished publication.

There were several WordPress versions, a Publii version, and even Astro with WordPress behind it before Hugo. I wrote about that history in why I moved rabin.blog to Hugo (opens in a new tab).

The reasons for choosing Hugo still make sense to me: portable Markdown files, less maintenance, and no database needed for editing. I wanted a simple site I could keep around.

Those requirements came along to this version. The content still lives in files, and the site still builds into static pages hosted on Cloudflare Pages.

What I wanted to explore this time was how much of the reading experience I could shape myself. How should a short fix sit beside a longer article? How do I connect posts that belong together? And how much interface does a small technical journal actually need?

Building the thing gives me a way to work through those questions. Reading about Astro would only get me so far.

A brief history since 2017

This may look like a lot, but without these experiments, there is no way to do hands on learning.

A quieter design, with a few useful details

As you can see this site is heavily influenced from Ricardo Fuhrmann’s blog. I liked its restrained layout and the way the writing had room to breathe. I used that as a direction, then built around my own content/component and preferences.

There is a frame around the page, clear typography, thin dividers, and a little color to help with links and navigation. The post lists are simple rows. The article gets the space.

Minimalist, but there are still things to use. Longer posts have a contents navigation, code blocks have copy buttons, and internal links can show a preview before you leave the page. The theme control follows your system preference by default, with Dark and Light choices if you want to set one yourself.

I want these details to help when you need them, then let you get back to reading.

Articles and Notes have different jobs

The blog now has two post types: Articles and Notes.

An Article gives me room to explain something properly. It might be a practical guide, an implementation story, or a piece like this one, where the reasons matter as much as the result.

A Note is for one useful thing. A command, a small fix, or an observation I will probably need again. It does not need to grow into a full guide just to earn a place on the site.

That suits the original reason I started rabin.blog. Some things need a longer explanation. Sometimes all I have is a fix that might save somebody twenty minutes.

Both types use the same content system. Their labels tell you roughly what to expect before you open them.

Some articles belong together

I also have series, so related posts can have an intended reading order.

You can see an example in Building My NixOS Workstation. It connects the desktop setup, application installation, Affinity V2, and audio posts into a path you can follow.

A post in a series tells you where you are, lets you open the list of installments, and provides previous and next links within that series. You can still read an individual post on its own.

Tags remain useful for browsing a topic. A series gives me a way to say, “these go together, and this is the order that makes sense.” A relevant Note can belong to a series too.

Keeping the writing close to Obsidian

I still want to write in Obsidian. Changing the site should not require moving all my writing into another system.

For this project, src/content is the Obsidian vault as well as the source Astro reads. Astro Composer and the Vault CMS plugin are configured to help manage those files. The full create, edit, and publish routine still needs a hands-on check in Obsidian; that is the workflow I am building toward.

New posts use MDX. If that name is unfamiliar, think of Markdown with the option to place a supported component inside the writing. Most of the post can stay ordinary paragraphs, headings, and lists.

I added Steps for explaining an ordered process and FileTree for showing folders and files. A directory structure is much easier to follow when I can show it instead of describing every slash in a paragraph.

Why I kept the layout structure small

Early on, I did not create a separate .astro file for every layout detail. I wanted to get the shared reading page working and see what actually needed to be reused.

An .astro file describes part of the site interface. A post does not need its own one: the shared post route reads the content and puts it into the same layout. That means I can adjust the byline or reading structure in one place instead of repeating the change across articles.

There are reusable components now, for things like archives, comments, and series navigation. I am keeping those around recognizable jobs as the site develops. I do not need to decide every possible future layout before writing the next post.

Here is a partial view of the actual src/ structure:

The writing lives under content, the shared page shell lives under layouts, and the styles have their own place. The file tree above is also an example of the FileTree component inside a post.

For new posts, images stay beside index.mdx in its images/ folder. Moving or finding a post is easier when its pictures are next to it. Older imported media stays in attachments, which is published as public site files. Site-owned artwork for social cards lives separately under assets/og.

The older Markdown posts still work. I did not need to convert the whole archive to MDX to start using it for new writing.

A few things carried over, a few things got easier

Comments still use the same self-hosted Isso service I used with Hugo. The integration keeps the existing post paths as thread identifiers, so changing the site generator does not require starting a new comment system. The comment form has been checked loading; submitting a comment is still a separate check to finish.

Open Graph images are the preview pictures you see when sharing a link. The site generates those during the build when a post does not already have an explicit cover image. If I supply a cover, that image takes precedence. One less repetitive publishing task, while keeping the choice when a post needs its own artwork.

The migration also preserves the established post URLs. Those details are less visible than a new layout, but they matter when an old link is how somebody finds the answer.

About 18 hours got me to this version. Reusing parts of the Hugo work helped, and there are still details to improve as I use it.

I expect the next useful changes will come while writing an actual post or reading an older one on my phone. That is usually where I find out whether an idea was helpful. For now, I have a quieter place to write, a better way to connect the writing, and another experiment to learn from.