DEV Community: Emanuele

Is WordPress dead? (Or just too stubborn to notice?)

Emanuele — Sun, 29 Mar 2026 00:33:00 +0000

I've been building and maintaining WordPress sites for years. Clients, side projects, quick landing pages — WordPress was always the default answer. Need a website? WordPress. Need a blog? WordPress. Need a portfolio? WordPress with a theme and three plugins.

And for a long time, that made sense. WordPress powered a massive share of the web, had a plugin for everything, and you could hand it off to a non-technical client who could update their own content. The ecosystem was unmatched.

But lately, every time I spin up a new WordPress instance, I can't shake the feeling that I'm solving a 2026 problem with a 2006 tool. And I don't think I'm alone.

The weight problem

Let's start with the thing nobody wants to say out loud: WordPress is slow.

Not theoretically slow. Not "if you don't optimize it" slow. Slow by default. A fresh WordPress install with a commercial theme and a handful of essential plugins — contact form, SEO, caching, security — already ships more PHP, more database queries, and more JavaScript than most sites actually need.

And here's the painful number: fewer than half of WordPress sites on mobile pass Google's Core Web Vitals. For a platform that powers over 42% of the web, that's not a minor issue — that's a systemic design problem.

The response from the WordPress community is always the same: use a caching plugin, optimize your images, pick a lightweight theme, configure your CDN. In other words, spend hours undoing the bloat that WordPress introduced in the first place. You're not building a website at that point. You're performing surgery on one.

The plugin trap

WordPress's greatest strength — its plugin ecosystem — has quietly become its biggest liability.

There are over 70,000 plugins available. That sounds impressive until you realize that up to 97% of WordPress security vulnerabilities come from plugins. Every plugin you install is a dependency you now have to maintain, update, and trust. And while most site owners do keep WordPress itself updated, the plugin ecosystem is where things fall apart — outdated, abandoned, or poorly maintained plugins are the norm, not the exception.

But even setting security aside, the plugin model creates a weird kind of dependency. Want a contact form? Plugin. Want SEO metadata? Plugin. Want your site to load in under three seconds? Plugin that undoes what the other plugins did. Want to back up your site? Plugin. The average WordPress site runs somewhere between 20 and 30 plugins, each adding its own CSS, JavaScript, and database queries.

At some point you have to ask: if you need a dozen plugins just to make a basic site work properly, is the platform actually solving your problem — or is it the problem?

The hosting illusion

One of WordPress's selling points has always been cheap hosting. And it's true — you can get WordPress hosting for a few euros a month. What nobody mentions is why it's so cheap.

Budget shared hosting means your site shares a server with hundreds of others. Your PHP processes compete for CPU time. Your database queries queue up behind everyone else's. The result is a site that technically works but loads like it's on dial-up — especially under any kind of traffic spike.

The alternative is managed WordPress hosting, which is faster and more reliable but costs €20–50/month or more. At that point, you're paying cloud-tier prices for a CMS that still needs plugins, still needs updates, and still fails Core Web Vitals half the time.

Meanwhile, a static site built with any modern tool deploys to Cloudflare Pages, Netlify, or Vercel for free. Zero servers to manage. Global CDN included. Load times measured in milliseconds, not seconds.

The elephant in the room: the Mullenweg drama

I can't write about the state of WordPress in 2026 without mentioning this.

The ongoing conflict between Matt Mullenweg — WordPress co-creator and CEO of Automattic — and WP Engine has shaken the community in ways that go beyond a corporate lawsuit. Mullenweg blocked WP Engine customers from accessing WordPress.org updates, leaving sites unable to receive security patches. He expelled long-time contributors from the project. The legal battle dragged on through 2025 and into 2026.

Whether you side with Mullenweg or WP Engine isn't really the point. The point is that this episode exposed something uncomfortable: a huge chunk of the web's infrastructure depends on one person's goodwill and one company's business decisions. That's a governance risk that many developers and businesses hadn't fully considered — and it's pushing people to look at alternatives more seriously than before.

The real question: what do you actually need?

Here's where it gets interesting.

Think about the WordPress sites you've built or managed. How many of them were truly dynamic? How many actually needed a database, server-side rendering, user authentication, or a CMS backend?

In my experience, the answer is: far fewer than you'd expect. The vast majority of WordPress sites I've worked on were essentially static. A homepage, an about page, a services page, a contact form, maybe a blog. Content that changes once a month, if that.

For that kind of site, WordPress is not just overkill — it's the wrong architecture entirely. You're running a PHP application backed by a MySQL database, processing every page request on the server, just to deliver content that hasn't changed since last Tuesday.

The AI shift nobody's talking about

And this is where things get genuinely different from any "WordPress is dying" take you've read before.

We now have AI coding tools — Claude Code, OpenAI Codex, Google Gemini CLI — that can generate a complete, production-ready website from a conversation. Not a template. Not a wireframe. An actual, deployable site.

I'm not talking about toy demos. I mean: you describe what you want — a portfolio site with these sections, this color scheme, a contact form, responsive layout — and in a few minutes you have clean HTML, CSS, and JavaScript. No plugins. No database. No server. No security patches to install next month.

The output is a static site that loads instantly, scores 100 on Lighthouse, costs nothing to host, and does exactly what 80% of WordPress sites do — except faster, lighter, and with zero maintenance overhead.

And here's the part that makes WordPress developers uncomfortable: the non-technical client who used to need WordPress because they couldn't code? They can now describe what they want in plain language and get a working site. The abstraction layer that WordPress provided — "you don't need to know how to code" — is being replaced by a better abstraction: "you don't even need to know what a CMS is."

What this looks like in practice

Let me be concrete. Here's what a typical "WordPress project" looks like when you replace it with an AI coding tool and a static site approach.

The old way (WordPress): Buy hosting. Install WordPress. Pick a theme. Customize the theme (fight the theme). Install 10–15 plugins. Configure each plugin. Set up caching. Set up backups. Set up security. Write content. Hope nothing breaks on update day. Total setup time: a weekend, maybe more. Ongoing maintenance: constant.

The new way: Open Claude Code, Codex, or Gemini. Describe the site. Review the output. Deploy to Cloudflare Pages or Netlify. Done. Total setup time: an afternoon, probably less. Ongoing maintenance: near zero — there's nothing to update because there's nothing running.

The site is faster, more secure (there's nothing to hack), cheaper to host (free, in most cases), and easier to modify (ask the AI to change it).

Where WordPress still wins

I promised honesty, so here it is.

WordPress is still the right choice in some scenarios. If you need a site where multiple non-technical users publish content daily — a news site, a multi-author blog, a magazine — the CMS workflow is hard to replace. WordPress's editorial interface, revision history, and role management are mature and battle-tested.

If you're running WooCommerce with thousands of products, complex inventory, and payment integrations, you're in territory where static sites and AI prompts genuinely can't compete. E-commerce at scale is a different beast.

And if you already have a WordPress site that works, that's maintained, and that serves your needs — there's no reason to burn it down. Migration for its own sake is just engineering vanity.

But for everything else?

For the freelancer building a client's brochure site. For the startup that needs a landing page. For the developer who wants a portfolio. For the small business that needs an online presence with a contact form and a map. For the blogger who posts once a week.

WordPress is not the answer anymore. It's the habit.

The tools have changed. A static site generated by AI, deployed to a global CDN, with no database, no plugins, and no server to maintain, will outperform a WordPress site in every measurable way — speed, security, cost, and reliability.

Final thoughts

WordPress isn't dead. But it's no longer the default. And the fact that we keep reaching for it anyway says more about our habits than about the technology.

The next time someone asks you to build a simple website, before you type wp-admin into a browser, ask yourself: does this project actually need a CMS, a database, a server, and thirty plugins? Or does it need five static pages that load in 200 milliseconds?

If the answer is the latter — and it usually is — you have better options now. Options that didn't exist two years ago. And they're getting better every month.

WordPress had a great run. For a lot of use cases, that run is over.

How I replaced paid hosting with a €100 home server (and saved hundreds)

Emanuele — Wed, 25 Mar 2026 10:29:29 +0000

The slow bleed of cloud costs
A few years ago, I did a rough calculation of everything I was paying for hosting.

VPS here, managed instance there, a database service I barely touched. Nothing individually catastrophic — but add it all up and I was spending somewhere between €150 and €200 per year on infrastructure for projects that maybe five people used, including me.

The worst part? Most of it was idle. Side projects running 24/7 “just in case.” APIs that handled a handful of requests per day sitting on machines provisioned for production workloads.

But here’s what I hadn’t fully accounted for: the SaaS subscriptions on top of that. Password manager, note-taking app, file sync, photo backup, private Git — small monthly fees that, combined, easily added another €10–15 per month. Services I was paying for, where the open source alternative exists and runs perfectly well on your own hardware.

I wasn’t paying for what I used. I was paying for the comfort of not thinking about it.

Then I bought a mini PC for €100, and that changed.

The actual problem with home hosting
Moving services home sounds obvious once you have a home server — until you realize why most developers don’t bother.

It’s not the hardware. It’s not even the networking. The real friction comes from one very unglamorous fact:

Your ISP gives you a dynamic public IP.

It changes. Randomly. Sometimes weekly, sometimes daily. And every time it does, every DNS record you’ve set up points to the wrong address, and your services go dark.

That’s the wall most people hit. They set something up, it breaks a few days later, and they go back to paying for a VPS where someone else manages this stuff.

What I needed wasn’t just a server. I needed a stack that could handle this reliably, without me babysitting it.

The stack
Here’s what I landed on after some iteration. Each piece has a specific role, and together they cover everything that makes home hosting actually work.

Hardware: a mini PC
I went with a small x86 mini PC — the kind you can find for €80–120. Fanless, low power draw (~10W), small enough to sit quietly in a corner.

Today, that machine runs 60 containers with a mix of personal tools, dashboards, self-hosted SaaS replacements, and side projects — all without breaking a sweat. The resources that feel modest on paper (8GB RAM, a mid-range CPU) are more than enough when your workloads are lightweight services, not production traffic.

The key insight is that you don’t need a proper server. For personal tools and homelab services, these machines are more than enough. And unlike a Raspberry Pi, you get x86 compatibility, more RAM options, and no SD card to corrupt at inopportune moments.

Running costs? Around €2–3 per month in electricity. The machine paid for itself in under three months.

Docker
Everything runs in containers. This isn’t a controversial choice in 2025, but it’s worth explaining why it matters specifically for home hosting.

With Docker, each service is isolated and reproducible. If something breaks, you tear down the container and bring it back up. Updates are docker pull and docker compose up -d. You can run a dozen services — or sixty — on one machine without them stepping on each other.

It’s also what makes self-hosting SaaS replacements practical. Nextcloud, Vaultwarden, Gitea, Paperless-ngx, Immich — nearly all of them ship as Docker images with official Compose files. Going from “I want to try this” to “it’s running” takes minutes, not an afternoon.

Nginx Proxy Manager
This one deserves more attention than it usually gets in homelab writeups.

Nginx Proxy Manager sits in front of all your services and handles two things that would otherwise be painful to manage: reverse proxying and SSL certificates.

You point your domain to your home IP, configure a proxy host in the UI, and NPM handles routing traffic to the right container — plus it automatically issues and renews Let’s Encrypt certificates. Every service gets HTTPS with no manual configuration.

The alternative is writing and maintaining Nginx configs by hand, which works fine until you have eight services and forget what any of the blocks do. NPM wraps all of that in a clean interface without hiding the underlying logic when you need it.

Cloudflare
My domains go through Cloudflare, and this is one of those decisions that has paid off repeatedly.

Beyond DNS management, Cloudflare acts as a reverse proxy for your public-facing services — which means your real home IP is never exposed in DNS records. You get DDoS protection, caching, and the ability to toggle traffic on and off at the CDN layer.

The free tier covers everything you need for a homelab setup. The API is solid and well-documented, which matters for the next piece.

Solving dynamic DNS
The dynamic IP problem is well-known, and there are plenty of scripts floating around that solve it. The issue is that scripts are opaque: they run, you hope they work, and when they don’t, you have no idea why.

What you want is something with visibility — logs, a dashboard, support for multiple DNS providers, and a UI you can check instead of SSH-ing into a machine to grep log files.

DriftDNS is a self-hosted DDNS manager that does exactly this. It runs as a container, checks your public IP on a configurable interval, and updates your DNS records automatically when it changes. The dashboard shows your current IP, the last sync time, all configured endpoints, and a log of every update. It currently supports Cloudflare and AWS Route53, with more providers on the roadmap.

How the pieces fit together
The request flow once everything is running:

A user hits myapp.example.com
Cloudflare resolves the DNS record (kept current by DriftDNS) and proxies the request to your home IP
Your router forwards the request to the mini PC
Nginx Proxy Manager routes it to the correct Docker container
The container handles the request

DriftDNS runs quietly in the background. If your IP changes at 3am, it’s updated before you wake up.

The numbers
One-time cost: — Mini PC: ~€100

Ongoing monthly costs: — Electricity: ~€2–3/month

What a comparable cloud setup would cost: — 1–2 VPS instances: €10–30/month — SaaS subscriptions for equivalent tools: €20–30/month — Total: €30–60/month → €360–720/year

The math works out quickly.

Tools you need
To replicate this setup, these are the main components:

• Docker → docker.com

• Nginx Proxy Manager → nginxproxymanager.com

• Cloudflare → cloudflare.com

• DriftDNS → github.com/emanueledeamicis/DriftDNS

All of them are free. Cloudflare has paid tiers, but the free plan is more than sufficient for a homelab.

Honest tradeoffs
Reliability depends on your home network. If your internet goes down, your services go down. For anything with real SLA requirements, this isn’t the right architecture.

Bandwidth. For most personal use cases this isn’t an issue — especially if you’re on fiber, which is increasingly common. If you’re serving large files to many users simultaneously, you might eventually hit residential upload limits. For everything I run, I’ve never come close.

Initial setup takes time. The first weekend you spend configuring this, it will feel like more work than just paying for a VPS. That’s accurate. After that, it mostly runs itself.

Final thoughts
I’m not suggesting everyone should shut down their cloud accounts. For production systems and anything requiring guaranteed uptime, cloud providers exist for good reasons.

But there’s a category of workloads — personal projects, homelab services, developer tools, SaaS alternatives, experiments — where the default choice of “spin up a VPS” or “pay for a subscription” is mostly habit, not necessity.

If you have a spare machine or can justify a €100 purchase, the tools to build this stack are mature, well-documented, and genuinely enjoyable to work with.

Sixty containers, a few euros a month in electricity. It’s a good trade.