Table of Contents

Why I Moved My Blog from WordPress to Rust

By Artur Kraft6 minutes read


For years, my personal blog lived happily on WordPress. I’ve built tons of WordPress sites — from small business pages to full-blown ecommerce shops — and I still believe it’s one of the most powerful, flexible, and user-friendly platforms out there.

But as my workflow evolved, and as I spent more time experimenting with Rust, SwiftUI, and Kotlin, I started to feel that WordPress was too heavy for what I needed my personal site to be. My blog isn’t a store, it’s not content-heavy, and it doesn’t need user accounts or fancy backend logic. It’s just a space to share thoughts, projects, and ideas. So I made the move — from WordPress to Zola, a static site generator written in Rust.

Why I Chose a Static Site Generator

A static site generator (SSG) takes plain text files (like Markdown for posts) and compiles them into static HTML pages. There’s no live server-side code running, no database to query, and no dynamic content that needs to load on the fly. Everything is prebuilt at deploy time.

For a personal blog, this is perfect. It’s simple, lightweight, and incredibly fast. Once the site is generated and deployed to my server, it’s ready — no PHP, no database calls, no WordPress core updates. Just straightforward, static HTML, CSS, and JavaScript files served directly from my VPS.

And the beauty of it? I don’t lose interactivity — I just handle it differently. For comments, for example, I pull in discussion threads from Mastodon posts tied to each article. That means people can comment via Mastodon, and my blog displays those comments — all while staying completely static. No external comment systems, no spam filters, no maintenance headaches.

Why Rust (and Zola)?

Rust has become one of my favorite languages over the past few years, and there are several reasons for that. First and foremost, Rust combines high performance with memory safety — two qualities you rarely get together. It compiles to native machine code like C or C++, which makes it blazingly fast, but it also eliminates entire classes of bugs that usually plague systems programming, like segmentation faults or data races.

For someone like me who loves clean, efficient code, writing in Rust is incredibly satisfying. The compiler catches so many mistakes before you even run your program that by the time it compiles successfully, you can be pretty confident it’s going to do exactly what you meant. It enforces discipline, but in a good way.

Zola, being written in Rust, benefits from all that speed and reliability. The site builds nearly instantly, even with lots of posts. Deployments are painless — no databases to migrate, no cache invalidation issues, just push and go. And maintenance is almost nonexistent. Once it’s set up, it just works.

VPS vs Shared Hosting

Another factor in this setup is how I host my sites. I run everything on a VPS (Virtual Private Server), not on shared hosting. It’s a big difference.

Shared hosting means your website shares CPU, memory, and bandwidth with dozens or even hundreds of other sites. It’s affordable but limited — if someone else on the same server gets a traffic spike, your site slows down too. You also can’t configure much beyond the basics.

VPS, on the other hand, gives you isolated resources. It’s still virtualised, but you get your own environment with root access. That means I can install exactly what I need, tune system settings, run the latest versions of PHP, Nginx, and databases, and really optimise performance.

For static sites, VPS hosting is a dream. With no database or backend logic keeping the site alive, the server has almost nothing to do except deliver HTML files as fast as possible — and that happens almost instantly. My current setup can serve hundreds of requests per second without breaking a sweat.

Security and Peace of Mind

One of the biggest wins from this move is security. With a static site, there’s virtually nothing to hack. No login pages, no admin panels, no SQL databases, no PHP files running on the server. Every page is just static HTML, and every asset is cached and immutable.

That gives me incredible peace of mind. I don’t have to worry about plugin vulnerabilities or outdated libraries. When I want to make a change, I regenerate the site locally, deploy it, and that’s it. Even the comments, since they’re pulled in from Mastodon via API at build time, don’t open any attack surface on the live site.

I Still Love WordPress

Now, all that said — I still love WordPress. Seriously. I use it for the majority of my client projects, and for good reason.

When done right, nothing beats a well-built WordPress site. It’s an incredibly capable CMS with a mature ecosystem, and it’s unmatched for ecommerce, content management, and dynamic websites. You get a powerful admin interface, thousands of high-quality plugins, and a lot of flexibility.

The key, though, is that it has to be set up professionally. WordPress gets a bad reputation mostly when people run it on cheap shared hosting, with outdated themes or plugins, or rely too heavily on AI-generated setups without understanding the tech behind it. That’s where performance, security, and stability start to suffer.

For my clients, I make sure everything runs on the latest stable PHP version, with carefully selected plugins, optimised caching, and cloud or VPS hosting. I also automate frequent backups and apply tight security measures to ensure reliability. When treated like a real software project, WordPress performs beautifully — it’s fast, secure, and can scale surprisingly well.

The Right Tool for the Job

For me, this whole migration was about picking the right tool for the job. My blog is a simple, personal space — I don’t need a CMS, a database, or backend logic. So a static site built with Rust feels perfect: modern, efficient, fast, and maintenance-free.

But when it comes to client work — especially ecommerce or business sites — WordPress is still king. It empowers people who aren’t developers to manage their own content, and it gives me as a developer the flexibility to build anything from a straightforward brochure site to a complex online store.

Different tools for different needs — and that’s exactly how I like it.

Get in touch if you have any questions or want to chat about your own setup. I’d love to hear your thoughts!

Comments

You can comment on this blog post by publicly replying to this post using a Mastodon or other ActivityPub/Fediverse account. Known non-private replies are displayed below.

Open Post