In January, I decided to rebuild my personal WordPress blog on Azure.
Not as a demo.
Not as a “hello world.”
But as a long-running, low-cost, production-grade personal workload—something I could realistically live with for years.
What followed was a reminder of why real cloud engineering is never about just clicking “Create”.
Why I Didn’t Use App Service (Again)
I initially explored managed options like Azure App Service and Azure Container Apps. On paper, they’re perfect. In practice, for a personal blog:
- Storage behavior mattered more than storage size
- Hidden costs surfaced through SMB operations and snapshots
- PHP versioning and runtime controls were more rigid than expected
Nothing was “wrong” — but it wasn’t predictable enough for a small, fixed budget site.
So I stepped back and asked a simpler question:
What is the most boring, controllable architecture that will still work five years from now?
The Architecture I Settled On
I landed on a single Ubuntu VM, intentionally small:
- Azure VM: B1ms (1 vCPU, 2 GB RAM)
- OS: Ubuntu 22.04 LTS
- Stack: Docker + Nginx + WordPress (PHP-FPM) + MariaDB
- Disk: 30 GB managed disk
- Access: SSH with key-based auth
- Networking: Basic NSG, public IP
No autoscaling. No magic. No illusions.
Just something I fully understand.
Azure Policy: A Reality Check
The first thing that blocked me wasn’t Linux or Docker — it was Azure Policy.
Every resource creation failed until I added mandatory tags:
envcostCenterowner
Not just on the VM — but on:
- Network interfaces
- Public IPs
- NSGs
- Disks
- VNets
Annoying? Slightly.
Realistic? Absolutely.
This is what production Azure environments actually look like.
The “Small” Issues That Matter
A few things that sound trivial — until you hit them at 2 AM:
- SSH keys rejected due to incorrect file permissions on Windows/WSL
- PHP upload limits silently capped at 2 MB
- Nginx + PHP-FPM + Docker each enforcing their own limits
- A 129 MB WordPress backup restore failing until every layer agreed
- Choosing between Premium vs Standard disks for a low-IO workload
None of these are headline features.
All of them determine whether the site actually works.
Cost Reality
My target budget: under $150/month total, including:
- A static site (
tanolis.us) - This WordPress blog
The VM-based approach keeps costs:
- Predictable
- Transparent
- Easy to tune (disk tier, VM size, shutdown schedules)
No surprises. No runaway meters.
Why This Experience Matters
This wasn’t about WordPress.
It was about:
- Designing for longevity, not demos
- Understanding cost behavior, not just pricing
- Respecting platform guardrails instead of fighting them
- Choosing simplicity over abstraction when it makes sense
The cloud is easy when everything works.
Engineering starts when it doesn’t.
What’s Next
For now, the site is up.
Backups are restored.
Costs are under control.
Next steps — when I feel like it:
- TLS with Let’s Encrypt
- Snapshot or off-VM backups
- Minor hardening
But nothing urgent. And that’s the point.
Sometimes the best architecture is the one that lets you stop thinking about it.
Add to favorites
