Leaving WordPress: less waste, more control on a self-hosted stack

We just moved cloudarch.es off WordPress onto a small, purpose-built stack: Next.js, Postgres, and Docker Compose we own end to end. Same posts and categories, no comment plugin zoo — and numbers that are easier to defend than a CMS plugin list.

This is not an anti-WordPress rant. WordPress is fine for many sites. For a technical blog we already host and monitor ourselves, a self-managed app was the cleaner fit: fewer moving parts, clearer resource use, and a security model we can actually describe.

What we measured

We ran a side-by-side on the same host: the old WordPress + MariaDB stack versus the new blog + Postgres stack, after a few page hits so both were “warm.”

Runtime memory

Stack	Containers	Memory (approx.)
New blog	web + Postgres + backup sidecar	~244 MiB (≈206 + 36 + 2)
WordPress	PHP/Apache + MariaDB	~284 MiB (≈156 + 128)

At light load they are in the same ballpark. WordPress can look tiny when cold, then grow as workers and caches wake up. The Next.js process sits around ~200 MiB steady; MariaDB used more RAM than Postgres for the same content set.

Storage

	WordPress	New blog
Database volume	~270 MB (MariaDB)	~47 MB (Postgres)
App / files volume	~2.1 GB (core + plugins + themes + uploads)	~1.8 GB (mostly media)

The database is roughly five to six times smaller after a clean migration of the same articles. Media footprint is similar — we kept the uploads. What we dropped was years of CMS machinery we were not using.

Efficiency is more than RAM

• Processes: the blog web container stays small (a couple of Node processes) instead of a pool of Apache workers waiting for PHP.
• Surface area: no plugin marketplace on the critical path. Dependencies are pinned in our image and updated when we choose.
• Ops tax: less background noise from XML-RPC, login probes, and theme/plugin update churn hitting the app itself. The reverse proxy still sees the internet; the app no longer has to speak WordPress’s dialect.
• Observability: first-party metrics (visits, clicks, countries, top posts) plus container metrics from cAdvisor into the Prometheus/Grafana stack we already run for CloudArch.

We have not published a heavy load-test bake-off yet. For this site and traffic, RAM is comparable; storage, attack surface, and day-to-day ops clearly favor the new stack.

Why self-hosted (and self-managed) wins here

Self-hosting is not automatically “cheaper” or “safer.” It is accountable. We know which containers listen where, which secrets exist, how backups are encrypted, and who can publish. That accountability is the point of CloudArch packs in general: reverse proxy, storage, monitoring, and backups you can restore-test — not a black-box CMS tenancy.

• You own the blast radius. One Compose project, one Postgres, one admin path. No third-party themes or plugins that ship code into production without a review you control.
• You own the data path. Content lives in Postgres we back up with age-encrypted archives, retained locally and synced to our own Nextcloud — not locked in a proprietary CMS export format.
• You own the security baseline. Hardened headers, no public comment/auth surface beyond a single admin login, sessions we define, and a dependency tree we can audit in one repo.
• You own the efficiency story. When memory or disk looks wrong, we can fix the app or the image — not hunt through plugin settings hoping a toggle exists.

Security without the CMS tax

WordPress’s strength — extensibility — is also its cost. Every plugin and theme is another trust relationship, another update cadence, another place where a vulnerability can land between you and your readers. A purpose-built blog with a tiny admin surface and a known schema does not eliminate risk, but it shrinks the places risk can hide.

Concretely for this migration:

• No plugin ecosystem on the public site
• No xmlrpc / wp-login surface on the app
• Secrets via Docker secrets and hashed admin credentials — not a sprawling options table
• Same monitoring and alerting fabric as the rest of our self-hosted fleet

Self-managed software only stays secure if you keep shipping updates. The difference is that updates are ours: rebuild the image, migrate the schema, redeploy Compose. That is boring — and boring is good.

What we are still tightening

• Slimmer production images (standalone Next.js output instead of a fat layer with full node_modules)
• Richer Grafana panels for per-container CPU/memory now that cAdvisor is healthy again on this host
• Load tests when we want hard numbers on latency under stress

Takeaway

For cloudarch.es, leaving WordPress was less about chasing the last megabyte of RAM and more about running a stack we understand. Similar memory under light load, a much smaller database, less unused surface, and a security model that matches how we already operate self-hosted infrastructure.

If you are already living in Docker, Prometheus, and encrypted backups, a purpose-built blog is often the efficient choice — not because WordPress cannot scale, but because you can, when you own every layer.