Why I Built Custom Domains with A Records Instead of CNAME (and why it matters)
After shipping SnapDeploy's custom domain feature last month, I got asked: "Why A records? Everyone uses CNAME."
Here's the thing - CNAME records have a dirty secret: they don't work on root domains.
Try pointing example.com (not www.example.com) to a CNAME. Your DNS provider will either reject it or do "CNAME flattening" behind the scenes. It's messy.
The Problem I Kept Seeing
Users would sign up, deploy their container, then message me:
"I want to use mydomain.com but your docs say CNAME and my DNS won't let me"
This happened at least once a week.
The Fix: A Records
Switched the entire system to use A records instead:
Works on root domains (
example.com) ✓Works on subdomains (
api.example.com) ✓No CNAME flattening weirdness ✓
Faster DNS resolution ✓
Setup is now dead simple:
Add domain in dashboard
Copy the IP address
Add A record in your DNS
Wait 10 min for SSL
Quick Comparison
PlatformRecord TypeRoot Domain?SnapDeployA RecordYesRenderCNAMENeeds workaroundRailwayCNAMENeeds flatteningHerokuCNAMENo
Lesson Learned
Sometimes the "standard" way isn't the best way. CNAME is everywhere because that's what tutorials copy from each other. But A records solve the root domain problem that frustrates users.
Small infrastructure decisions = big UX impact.
Custom domains available on Starter plan ($39/mo) and up. Free tier gets a subdomain at yourapp.snapdeploy.dev.
What infrastructure decisions have you made that seemed small but had outsized impact?
