How I mapped an entire platform stack to one domain using Cloudflare
One domain. Six subdomains. Airflow, Okta, Hashnode, email routing, Atlassian verification, and a redirect rule — all managed through Cloudflare's free DNS for $10/year.
When I set out to build a personal automation platform, I wanted everything to live under a single professional domain. No more auto-generated vendor subdomains — just clean, memorable URLs that look like real production infrastructure. Here's exactly how I mapped an entire stack to a single custom domain using Cloudflare.
The complete domain map
| Subdomain | Points to | Record type |
|---|---|---|
airflow.yourdomain.dev |
Self-hosted app on GCP VM | A record |
blog.yourdomain.dev |
Hashnode blog | CNAME |
login.yourdomain.dev |
Okta tenant | Redirect Rule |
you@yourdomain.dev |
Forwards to Gmail | MX + Email Routing |
admin@yourdomain.dev |
Service signups (Okta, GCP) | MX + Email Routing |
dev@yourdomain.dev |
Developer tools (GitHub, etc.) | MX + Email Routing |
Why Cloudflare for DNS?
I registered my .dev domain through Cloudflare Registrar at cost price (~$10/year) with no markup. The real value is the feature set that comes completely free: WHOIS privacy, SSL proxying, redirect rules, email routing, and a clean API for automation.
Cloudflare's free DNS tier is genuinely enterprise-grade. The same infrastructure that protects Fortune 500 companies handles a $10/year personal domain identically.
DNS record by record
1. Self-hosted app — A record
The simplest record type. An A record maps a hostname directly to an IPv4 address. For any self-hosted service on a cloud VM with a reserved static IP, this is the right record type.
| Type | Name | Content | Proxy |
|---|---|---|---|
| A | airflow | <your static IP> |
DNS only |
Key detail: proxy status must be DNS only (grey cloud), not proxied (orange cloud). When your VM handles its own SSL via Let's Encrypt and Nginx, Cloudflare proxying would cause a double-SSL conflict. Always use DNS only for self-managed certificates.
2. Third-party hosted service — CNAME record
A CNAME is an alias — it says "resolve this hostname as if it were that other hostname." Use it whenever a SaaS platform gives you a target hostname to point at rather than an IP address.
| Type | Name | Target | Proxy |
|---|---|---|---|
| CNAME | blog | hashnode.network | DNS only |
Again DNS only — the hosting provider provisions its own SSL certificate for your custom domain. Cloudflare proxying would intercept that certificate handshake and break it.
3. Vendor tenant redirect — Cloudflare Redirect Rule
This is where it gets interesting. Some SaaS platforms (like Okta's free tier) don't support custom domains natively. Cloudflare's redirect rules let you create a branded subdomain that redirects to the vendor URL — giving you a clean URL without needing the vendor's paid plan.
Rule: If hostname equals login.yourdomain.dev
Then: Static redirect → https://your-tenant.okta.com
Status: 302
Important: redirect rules only fire on proxied DNS records. You need a dummy A record pointing to a placeholder IP with the orange cloud enabled. Cloudflare intercepts the request before it ever reaches that IP and fires the redirect.
| Type | Name | Content | Proxy |
|---|---|---|---|
| A | login | 192.0.2.1 (placeholder) | Proxied (orange cloud) |
| Rule | login.* | → your-tenant.okta.com | — |
4. Business email — MX + Email Routing
Cloudflare Email Routing is one of the most underrated free features in DNS management. It lets you create unlimited custom email addresses that forward to any destination inbox — with zero mail server setup.
| Type | Name | Content | Priority |
|---|---|---|---|
| MX | @ | route1.mx.cloudflare.net | 13 |
| MX | @ | route2.mx.cloudflare.net | 30 |
| MX | @ | route3.mx.cloudflare.net | 19 |
| TXT | @ | v=spf1 include:_spf.mx.cloudflare.net ~all | — |
I created three addresses — a personal one, an admin one for service signups, and a dev one for developer tools — all forwarding to Gmail. Using separate addresses makes filtering and org-level email management trivial.
5. Third-party domain verification — CNAME + TXT
Many enterprise platforms (Atlassian, Google Workspace, etc.) require domain ownership verification before they trust your custom domain for email or SSO. They typically give you a set of CNAME records for DKIM email signing and a TXT record for verification.
| Type | Name | Purpose |
|---|---|---|
| CNAME | <vendor-prefix>._domainkey |
DKIM signing (primary) |
| CNAME | <vendor-prefix>._domainkey |
DKIM signing (fallback) |
| CNAME | <vendor>-bounces |
Email bounce handling |
| TXT | @ | Domain ownership proof |
The name format varies by vendor — always copy the exact values from their DNS setup wizard rather than typing them manually.
Key gotchas
Proxy status is the most important setting to get right. The orange cloud (proxied) routes traffic through Cloudflare's network — redirect rules fire, DDoS protection activates, but your own SSL won't work. The grey cloud (DNS only) passes traffic straight to your server — your own SSL works, but Cloudflare features don't apply. Know which mode each record needs before you add it.
Multiple TXT records on the root domain are perfectly valid. SPF, DMARC, vendor verification tokens — they all stack on @ without conflict. DNS supports multiple TXT records on the same name.
Never include your apex domain in the Name field. If your domain is yourdomain.dev and you want airflow.yourdomain.dev, just enter airflow as the Name — Cloudflare appends the domain automatically.
Redirect rules require a proxied DNS record to exist first. You can't target a hostname in a redirect rule unless there's a proxied record for it. Create a placeholder A record pointing to 192.0.2.1 with the orange cloud — Cloudflare will intercept before the request ever reaches that IP.
The complete DNS picture
| Type | Name | Purpose | Proxy |
|---|---|---|---|
| A | airflow | Self-hosted app VM | DNS only |
| CNAME | blog | Hosted blog platform | DNS only |
| A | login | Redirect rule placeholder | Proxied |
| MX | @ | Email routing (x3) | — |
| CNAME | vendor._domainkey (x2) | DKIM email signing | DNS only |
| CNAME | vendor-bounces | Email bounce handling | DNS only |
| TXT | @ | SPF + vendor verification | — |
| TXT | _dmarc | DMARC policy | — |
| Rule | login.* | Okta tenant redirect | — |
Total cost
| Component | Cost |
|---|---|
| Domain registration (.dev) | $10/yr |
| Cloudflare DNS | Free |
| Email routing (unlimited addresses) | Free |
| Redirect rules | Free |
| SSL proxying | Free |
| WHOIS privacy | Free |
| Total | $10/yr |
What's next
A few additions I'm planning: a status.yourdomain.dev uptime page, an api.yourdomain.dev subdomain for internal APIs, and eventually using Cloudflare Origin Certificates to properly terminate SSL at the edge rather than on the VM directly.
If you're setting up something similar or have questions about any of these DNS patterns, reach out at chander@inguva.dev.
Built with Cloudflare · Apache Airflow · Okta · Hashnode · Atlassian · GCP