TLS on a Simple Dockerized WordPress VM (Certbot + Nginx)

This note documents how TLS was issued, configured, and made fully automatic for a WordPress site running on a single Ubuntu VM with Docker, Nginx, PHP-FPM, and MariaDB.

The goal was boring, predictable HTTPS โ€” no load balancers, no Front Door, no App Service magic.


Architecture Context

  • Host: Azure Ubuntu VM (public IP)
  • Web server: Nginx (Docker container)
  • App: WordPress (PHP-FPM container)
  • DB: MariaDB (container)
  • TLS: Letโ€™s Encrypt via Certbot (host-level)
  • DNS: Azure DNS โ†’ VM public IP
  • Ports:
    • 80 โ†’ HTTP (redirect + ACME challenge)
    • 443 โ†’ HTTPS

1. Certificate Issuance (Initial)

Certbot was installed on the VM (host), not inside Docker.

Initial issuance was done using standalone mode (acceptable for first issuance):

sudo certbot certonly \
  --standalone \
  -d shahzadblog.com

This required:

  • Port 80 temporarily free
  • Docker/nginx stopped during issuance

Resulting certs live at:

/etc/letsencrypt/live/shahzadblog.com/
  โ”œโ”€โ”€ fullchain.pem
  โ””โ”€โ”€ privkey.pem

2. Nginx TLS Configuration (Docker)

Nginx runs in Docker and mounts the host cert directory read-only.

Docker Compose (nginx excerpt)

nginx:
  image: nginx:alpine
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - ./wordpress:/var/www/html
    - ./nginx/default.conf:/etc/nginx/conf.d/default.conf
    - /etc/letsencrypt:/etc/letsencrypt:ro

Nginx config (key points)

  • Explicit HTTP โ†’ HTTPS redirect
  • TLS configured with Letโ€™s Encrypt certs
  • HTTP left available only for ACME challenges
# HTTP (ACME + redirect)
server {
    listen 80;
    server_name shahzadblog.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/html;
        allow all;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

# HTTPS
server {
    listen 443 ssl;
    http2 on;

    server_name shahzadblog.com;

    ssl_certificate     /etc/letsencrypt/live/shahzadblog.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/shahzadblog.com/privkey.pem;

    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass wordpress:9000;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

3. Why Standalone Renewal Failed

Certbot auto-renew initially failed with:

Could not bind TCP port 80

Reason:

  • Docker/nginx already listening on port 80
  • Standalone renewal always tries to bind port 80

This is expected behavior.


4. Switching to Webroot Renewal (Correct Fix)

Instead of stopping Docker every 60โ€“90 days, renewal was switched to webroot mode.

Key Insight

Certbot (host) and Nginx (container) must point to the same physical directory.

  • Nginx serves:
    ~/wp-docker/wordpress โ†’ /var/www/html (container)
  • Certbot must write challenges into:
    ~/wp-docker/wordpress/.well-known/acme-challenge

5. Renewal Config Fix (Critical Step)

Edit the renewal file:

sudo nano /etc/letsencrypt/renewal/shahzadblog.com.conf

Change:

authenticator = standalone

To:

authenticator = webroot
webroot_path = /home/azureuser/wp-docker/wordpress

โš ๏ธ Do not use /var/www/html here โ€” that path exists only inside Docker.


6. Filesystem Permissions

Because Docker created WordPress files as root, the ACME path had to be created with sudo:

sudo mkdir -p /home/azureuser/wp-docker/wordpress/.well-known/acme-challenge
sudo chmod -R 755 /home/azureuser/wp-docker/wordpress/.well-known

Validation test:

echo test | sudo tee /home/azureuser/wp-docker/wordpress/.well-known/acme-challenge/test.txt
curl http://shahzadblog.com/.well-known/acme-challenge/test.txt

Expected output:

test

7. Final Renewal Test (Success Condition)

sudo certbot renew --dry-run

Success message:

Congratulations, all simulated renewals succeeded!

At this point:

  • Certbot timer is active
  • Docker/nginx stays running
  • No port conflicts
  • No manual intervention required

Final State (What โ€œDoneโ€ Looks Like)

  • ๐Ÿ”’ HTTPS works in all browsers
  • ๐Ÿ” Cert auto-renews in background
  • ๐Ÿณ Docker untouched during renewals
  • ๐Ÿ’ธ No additional Azure services
  • ๐Ÿง  Minimal moving parts

Key Lessons

  • Standalone mode is fine for first issuance, not renewal
  • In Docker setups, filesystem alignment matters more than ports
  • Webroot renewal is the simplest long-term option
  • Donโ€™t fight permissions โ€” use sudo intentionally
  • โ€œSimple & boringโ€ scales better than clever abstractions

This setup is intentionally non-enterprise, low-cost, and stable โ€” exactly what a long-running personal site needs.

Writing code is over

Ryan Dahl built Node.js.

Now he says writing code is over.

When the engineer who helped define modern software says this, pay attention.

Not because coding is dead.

Because the ๐˜ƒ๐—ฎ๐—น๐˜‚๐—ฒ ๐—บ๐—ผ๐˜ƒ๐—ฒ๐—ฑ.

๐—”๐—œ ๐—ฑ๐—ผ๐—ฒ๐˜€๐—ปโ€™๐˜ ๐—ฒ๐—น๐—ถ๐—บ๐—ถ๐—ป๐—ฎ๐˜๐—ฒ ๐—ฒ๐—ป๐—ด๐—ถ๐—ป๐—ฒ๐—ฒ๐—ฟ๐˜€.

๐—œ๐˜ ๐—ฒ๐—น๐—ถ๐—บ๐—ถ๐—ป๐—ฎ๐˜๐—ฒ๐˜€ ๐˜๐—ต๐—ฒ ๐—ถ๐—น๐—น๐˜‚๐˜€๐—ถ๐—ผ๐—ป ๐˜๐—ต๐—ฎ๐˜ ๐˜„๐—ฟ๐—ถ๐˜๐—ถ๐—ป๐—ด ๐—ฐ๐—ผ๐—ฑ๐—ฒ ๐˜„๐—ฎ๐˜€ ๐˜๐—ต๐—ฒ ๐—ท๐—ผ๐—ฏ.

๐—ง๐—ต๐—ฒ ๐—ข๐—น๐—ฑ ๐— ๐—ผ๐—ฑ๐—ฒ๐—น

Value lived in syntax.

Output was measured in lines of code.

๐—ง๐—ต๐—ฒ ๐—˜๐—บ๐—ฒ๐—ฟ๐—ด๐—ถ๐—ป๐—ด ๐— ๐—ผ๐—ฑ๐—ฒ๐—น

Value lives in systems thinking.

Output is measured in correctness, resilience, and architecture.

You can already see this shift.

The meeting where no one debates the code.

They debate the ๐—ฎ๐˜€๐˜€๐˜‚๐—บ๐—ฝ๐˜๐—ถ๐—ผ๐—ป.

The ๐˜๐—ฟ๐—ฎ๐—ฑ๐—ฒ๐—ผ๐—ณ๐—ณ.
The ๐—ณ๐—ฎ๐—ถ๐—น๐˜‚๐—ฟ๐—ฒ ๐—บ๐—ผ๐—ฑ๐—ฒ.

The code is already there.

The decision is not.

๐—ฆ๐˜†๐—ป๐˜๐—ฎ๐˜… ๐˜„๐—ฎ๐˜€ ๐—ป๐—ฒ๐˜ƒ๐—ฒ๐—ฟ ๐˜๐—ต๐—ฒ ๐˜€๐—ฐ๐—ฎ๐—ฟ๐—ฐ๐—ฒ ๐˜€๐—ธ๐—ถ๐—น๐—น.

๐—๐˜‚๐—ฑ๐—ด๐—บ๐—ฒ๐—ป๐˜ ๐˜„๐—ฎ๐˜€.

๐— ๐—ฌ ๐—ง๐—”๐—ž๐—˜๐—”๐—ช๐—”๐—ฌ

The future of software is not necessarily fewer engineers.

Itโ€™s engineers operating at a higher level of consequence.

Teams that optimize for systems will compound.

Teams that optimize for syntax will stall.

Rebuilding My Personal Blog on Azure: Lessons From the Trenches

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:

  • env
  • costCenter
  • owner

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.

IDesign Method: An Overview

Software projects often start small and cute, but can quickly become unmanageable as requirements change. This transformation is usually due to the lack of an appropriate architecture, or an architecture that is not designed for future change.

The IDesign Method: An Overview
The IDesign method, developed by Juval Lรถwy, provides a systematic approach to creating a software architecture that will stand the test of time. Let’s explore its key principles.

Avoid functional decomposition
The first principle of IDesign is to avoid functional decomposition – the practice of translating requirements directly into services. For example, if you’re building an e-commerce platform, don’t create separate services for “user management”, “product catalogue” and “order processing” just because those are your main requirements. Instead, IDesign advocates a more thoughtful approach based on volatility.

Volatility based decomposition
IDesign focuses on identifying areas of volatility – aspects of the system that are likely to change over time. For example, in our e-commerce example, payment methods might be an area of volatility, as you may need to add new payment options in the future.

The three-step process:
Identify 3-5 core use cases
What your system does at its most basic level. For our e-commerce platform, these might be:

Browse and search for products
Manage shopping cart
Completing a purchase

Identify areas of volatility
Identify aspects of the system that are likely to change. In our e-commerce example:
Payment methods
Shipping options
Product recommendation algorithms

Define services
IDesign defines five types of services:
Client: Handles user interaction (e.g. web interface)
Manager: Orchestrates business use cases
Engine: Executes specific business logic
Resource Access: Handles data storage and retrieval
Utility: Provides cross-cutting functionality

For our e-commerce platform example we might have:

A ShoppingManager – to orchestrate the shopping process
A PaymentEngine – to handle different payment methods
A ProductCatalogAccess – to manage product data

Design Principles and Patterns

Great software is not written.
Itโ€™s designed.

Most systems donโ€™t fail because of bad developers.
They fail because of bad design decisions made early โ€” and scaled blindly.

This is the foundation every serious engineer and tech leader must master ๐Ÿ‘‡

Design Principles & Patterns

๐Ÿ”น SOLID

SRP โ€“ One class, one reason to change
OCP โ€“ Extend, donโ€™t modify
LSP โ€“ Substitutions must be safe
ISP โ€“ Small, focused interfaces
DIP โ€“ Depend on abstractions, not concretes

SOLID isnโ€™t theory. Itโ€™s how you avoid rewriting your system every 6 months.

๐Ÿ”น GoF Design Patterns

1) Creational โ†’ Control how objects are created (Factory, Builder, Singleton)
2) Structural โ†’ Control how objects are composed (Adapter, Facade, Proxy)
3) Behavioral โ†’ Control how objects communicate (Strategy, Observer, Command)

Patterns are not โ€œfancy code.โ€
They are battle-tested solutions to recurring problems.

๐Ÿ”น DRY โ€“ Donโ€™t Repeat Yourself
Duplication is a silent killer.
It multiplies bugs and slows teams.

๐Ÿ”น KISS โ€“ Keep It Simple
Complexity is not intelligence.
Simplicity is.

๐Ÿ”น MVC + Repository + Unit of Work
Clean separation of concerns.
Predictable codebases.
Scalable teams.

Reality check:

Frameworks change.
Languages change.
Trends change.

Principles donโ€™t.

If you want to build:

Systems that scale
Teams that move fast
Products that survive years

Master the fundamentals.

Everything else is noise.