Mapping a Custom Domain to WordPress on Azure Container Apps (With Managed TLS & Zero Downtime)

I recently migrated my WordPress site to Azure Container Apps (ACA) and mapped my custom domain — shahzadblog.com — with a free managed TLS certificate, zero downtime, and a simple rollback plan. I’m documenting the full process here for my own records (and to help anyone doing the same).


🏗 Platform & Domain Setup

Platform

  • Azure Container Apps
  • Container App: ca-wp-v1
  • Region: East US
  • WordPress container already deployed and running
  • Public ACA URL was working before cutover

Domain

  • Domain: shahzadblog.com
  • Registrar: GoDaddy
  • DNS Hosting: Azure DNS (authoritative)
  • All records previously pointed to an older App Service

My goal was to:

  1. Map the apex domain (no www)
  2. Use ACA managed TLS certificate
  3. Validate ownership first (no traffic change)
  4. Perform a clean A-record cutover
  5. Keep rollback fast and reversible

🛡 Phase 1 — Ownership Validation (Safe Pre-Work)

From the Container App → Custom domains page, I added the domain to start the validation flow. Azure provided:

  • An A-record target (ACA environment inbound IP)
  • A TXT validation record (asuid.shahzadblog.com)

In Azure DNS, I created:

TXT record (ownership)

  • Name: asuid
  • Type: TXT
  • TTL: 5 minutes
  • Value: (the validation token from ACA)

This step does not affect live traffic — it only proves domain ownership.

I confirmed the record with:

nslookup -type=txt asuid.shahzadblog.com

🔁 Phase 2 — Prepare for Cutover (Low-Risk)

Before switching traffic, I temporarily lowered the TTL on the existing A record to 5 minutes so any rollback would be fast.

No IP change yet — just TTL.


🚦 Phase 3 — DNS Cutover to Azure Container Apps

When ready, I updated the A record:

A record (apex)

  • Name: @
  • Type: A
  • TTL: 5 minutes
  • Value: ACA Environment IP

Within a few minutes, traffic began resolving to ACA while the old endpoint was still active during cache expiry — resulting in zero downtime.


🔒 Phase 4 — Managed TLS Certificate

In the ACA Environment → Certificates page:

  1. Added a Managed Certificate
  2. Selected domain: shahzadblog.com
  3. Waited for status → Issued

Then I returned to the Container App:

  • Custom domains → Add binding
  • Selected the issued certificate
  • Binding type: SNI SSL

Final status:

Secured — Managed Certificate Attached

At this point:

  • HTTPS was active
  • Certificate valid
  • WordPress loaded normally under the new domain

🧪 Verification Checklist

  • https://shahzadblog.com loads in Incognito
  • Lock icon + DigiCert chain
  • WordPress admin + navigation working
  • DNS resolves to ACA IP
nslookup shahzadblog.com

🧹 Cleanup & Best Practices

  • Kept the TXT validation record (required for renewals)
  • Increased A-record TTL back to 1 hour after stability
  • Left old App Service stopped for rollback buffer (later retired)
  • Removed any extra TXT values so only the ACA token remains

💡 Notes & Lessons Learned

  • ACA managed certificates work smoothly once TXT + A records are aligned
  • Always validate ownership before DNS cutover
  • Lower TTL during migration makes rollback safe
  • Apex domains must use A-records, not CNAME
  • Keep TXT TTL short — it helps future cert renewals

🎯 Result

The migration completed successfully with:

  • Zero downtime
  • Clean HTTPS setup
  • Simple rollback safety
  • Fully container-hosted WordPress on ACA

This approach gives me flexibility to add Azure Front Door later if needed, without changing the app configuration.

FavoriteLoadingAdd to favorites

Comments

Leave a Reply


RECENT POSTS


Categories



Tags

ADO ai angular asian asp.net asp.net core azure ACA azure administration Azure Key Vault Azure Storage Blazor WebAssembly BLOB bootstrap Branch and Release flow c# containers css datatables design pattern docker excel framework Git guide HTML JavaScript jQuery json knockout lab LINQ linux powershell REST API smart home SQL Agent SQL server SSIS SSL SVG Icon typescript visual studio Web API window os wordpress


ARCHIVE


DISCLAIMER