Let me be clear from the start: I’m not leaving Micro.blog. In fact, I currently have more sites hosted on Micro.blog than not, including all my custom themes and documentation sites. Micro.blog is an excellent platform, and I continue to recommend it to anyone looking for a simple, community-focused blogging experience.
But for my personal blog, I wanted something different. I wanted to dive deeper into the IndieWeb rabbit hole, gain more granular control over security implementations, and have the flexibility to experiment with web technologies in ways that a hosted platform doesn’t easily allow. This post details that transition, the reasoning behind it, the decisions I made, and the technical implementations that shaped this site.
Why I Wanted More Control
I realized I was trying to do too much with one blog. I was mixing long-form posts with microposts (as is the Micro.blog practice), and neither format was thriving. With this transition, I made a key decision: eliminate microposts entirely from the blog.
My microposts now go to Mastodon. My blog focuses exclusively on longer-form writing. This clarity has already improved my writing workflow and processes. But it also makes it easy to keep longform writing above-the-fold without having to do some creative backend gymnastics.
Every post on this blog now has substance. I’m not aiming for daily posts; I’m aiming for posts worth reading. This shift has already improved my writing discipline. Instead of feeling pressure to post frequently, I can take time to develop ideas properly.
The Tech Stack
- Powered by Jekyll
- Pushed to GitHub
- Hosted by Netlify
Everything is version controlled with Git. I make changes locally, test them with the development server, commit to GitHub, and Netlify automatically builds and deploys. The entire process from commit to live deployment takes about two minutes. Netlify handles all the build commands and deploys the generated static files to their CDN with all the security headers and redirect rules configured.
A Custom Theme (Obviously)
Rather than using an off-the-shelf theme, I built a custom theme inspired by Steph Ango’s minimalist design philosophy. I implemented his Flexoki color scheme. Rest assured, this was not a copy/paste duplication, but a full from the ground up creation because I also wanted full IndieWeb and Webmention integration.
Getting Nerdy With IndieWeb Stuff
While Micro.blog has excellent IndieWeb support built in, I wanted to understand the mechanics more deeply. I wanted to implement webmentions from scratch, experiment with different presentation styles, and have full control over how my site participates in the open web.
Moving to Jekyll gave me the ability to use the jekyll-webmention_io plugin with completely custom templates. Instead of accepting default webmention displays, I could design exactly how likes, reposts, and replies appear on each post. I implemented a facepile display for reactions, custom reply views, and even configured throttled lookups so my build times wouldn’t balloon as mentions accumulated over time. Some of that was possible with Micro.blog, but not everything.
The webmention implementation is one of the most satisfying parts of this site (to me, at least). Webmention.io receives and stores all webmentions, while Bridgy acts as a bridge between social networks and the open web. When someone replies to my syndicated post on Mastodon or Bluesky, Bridgy automatically converts that reply into a webmention and sends it to Webmention.io. My site then fetches those mentions during the build process (and more) and displays them natively on the blog post.
Most of the above can easily be done by default in Micro.blog. It’s where normal people should stop. But I’m not a normal person and I had to go further. I wanted full control of the entire stack, including what gets pulled and how it’s displayed. This is where I spent the most time learning the ins and outs of the entire system.
Crossposting With Echofeed
Rather than manually crossposting, I use Echofeed to automatically syndicate blog posts to Mastodon, Bluesky, and Micro.blog. It monitors my RSS feed and posts new entries to each network with appropriate formatting. This keeps my social presence active while maintaining the blog as the canonical source. Every longform thing I publish originates here and flows outward.
Other Tools I’m Using
- Tinylytics for Privacy-Focused Analytics
- EmailOctopus for Newsletter
Making It Fast and Secure
Static site generation offers unmatched performance. The entire site is pre-built HTML, CSS, and JavaScript deployed to Netlify’s CDN. Various levels of compression and minifying not only happen, but I have full control over how it happens. The result is a site that loads nearly instantly and scores well on Lighthouse audits.
I wanted to achieve an A+ security rating with proper headers and content security policies. With full control over the deployment, I could implement comprehensive security headers including X-Frame-Options, Content Security Policy, and Permissions Policy. It’s the kind of detail work that’s easier when you control the entire stack. Is it necessary? For most people, probably not. But for someone who likes to learn and tinker, absolutely.
Is This Right for You?
This transition wasn’t about Micro.blog being inadequate. This was about my specific desire for deeper control, IndieWeb experimentation, and technical learning.
If you’re considering a similar move, ask yourself:
- Do I need this level of control?
- Am I comfortable with the technical complexity?
- Will I actually use the flexibility?
- Is the additional maintenance worth it?
For me, the answers were yes. But for most people, Micro.blog’s simplicity and community are exactly what they need. There’s no wrong answer, just different tools for different needs.
My personal blog is now built with Jekyll, but my theme documentation sites and other projects remain on Micro.blog because that’s where they belong. Each tool serves its purpose.
The beauty of the IndieWeb is that regardless of the platform, we’re all participating in the same open ecosystem through feeds, webmentions, and open standards. That’s what matters most.
Questions about the technical implementation? Find me on Mastodon or send me an email.