AMAdrian Marikar
← Back home

2026.06 / DNS CHECKLIST

Cloudflare DNS for self-hosted Coolify apps: proxy web, protect mail, avoid origin leaks

When a new self-hosted app is ready in Coolify, the exciting part is adding the custom domain and seeing HTTPS go green. The risky part is treating every DNS record the same. Web records, mail records, verification records, and internal hostnames have different jobs. If they are mixed together casually, the site may work while quietly exposing an origin address or breaking mail delivery.

This is the DNS checklist I use when a small VPS app moves from “it works on the server” to “it has a public domain”. It is written for the common pattern: GitHub deploys into Coolify, Coolify routes traffic to app containers, Cloudflare manages public DNS, and the same VPS may also host mail or other services.

Goal: make the public web path easy to discover and cache, while keeping non-web services explicit, boring, and not accidentally hidden behind a proxy that cannot serve them.

The mental model

Cloudflare's DNS docs describe the proxy status as a choice between DNS-only records and proxied records. Proxied records send supported web traffic through Cloudflare's edge before it reaches the origin. DNS-only records simply publish where a hostname points.

For a self-hosted Coolify app, that leads to a simple default:

The important distinction is not “orange cloud good, grey cloud bad”. The important distinction is what protocol the hostname serves and whether Cloudflare can safely sit in front of it.

A safe record shape

For a web app, the public DNS usually wants to be boring:

# Web app records
example.com       A or CNAME   <origin-or-target>   proxied
www.example.com   CNAME        example.com          proxied
app.example.com   CNAME        <origin-or-target>   proxied

# Mail and authentication records
example.com                    MX     mail.primary-domain.example   DNS-only
example.com                    TXT    v=spf1 mx -all                DNS-only
_dmarc.example.com             TXT    v=DMARC1; p=none; rua=mailto:[email protected]
selector._domainkey.example.com TXT   v=DKIM1; k=rsa; p=<public-key>

The placeholders matter. A public guide does not need to reveal a real origin address, private hostname, mailbox credential, signing-key material, or provider token. The reader needs the pattern: web records can be proxied; mail and authentication records should remain directly visible because other mail servers need to read them.

Coolify-specific checks

Coolify makes the app side pleasant, but DNS still has to agree with the route you configured. Before declaring a custom domain live, check these layers:

  1. The application has the intended public FQDN in Coolify.
  2. The DNS record exists for that exact hostname.
  3. The record is proxied if it is web traffic and you want Cloudflare in front.
  4. The app responds over HTTPS with the expected host header.
  5. The apex and www version either both work or one deliberately redirects to the other.
  6. The page's canonical URL, Open Graph URL, sitemap entry, and RSS links all use the chosen public URL.

That last point is easy to miss. A page can load in the browser while its metadata still points to a staging host, old project name, or unproxied hostname. Search and sharing systems will repeat whatever the HTML says.

How origin leaks happen

Origin leaks are usually not dramatic breaches. They are small leftovers:

Cloudflare's proxy can reduce casual exposure for web traffic, but it is not a magic privacy layer if other records or public files disclose the same origin. The fix is boring hygiene: publish only the hostnames you need, avoid literal server addresses in public docs, and scan the generated site before deploying infrastructure posts.

Verification commands

These commands are intentionally generic. Replace domains with your own and avoid pasting sensitive output into public pages.

# See what public DNS returns for the web hostname
dig +short example.com

# Check the canonical HTTPS response
curl -I https://example.com/

# Check www behaviour
curl -I https://www.example.com/

# Check whether HTML metadata names the production URL
curl -fsSL https://example.com/ | grep -E 'canonical|og:url|sitemap|feed'

# Check mail records separately
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

For proxied web hostnames, public DNS will normally return Cloudflare edge addresses rather than the origin. That is expected. For mail-related records, the goal is different: other mail servers need clear MX, SPF, DKIM, and DMARC answers.

Common mistakes

The practical launch checklist

  1. Choose the canonical hostname before editing metadata.
  2. Add the Coolify FQDN for that hostname.
  3. Create or update the Cloudflare web record and proxy it if appropriate.
  4. Keep MX, SPF, DKIM, DMARC, and mail hostnames DNS-only.
  5. Remove unused DNS records that point at the same origin.
  6. Verify curl -I responses for apex and www.
  7. Verify live canonical, Open Graph, RSS, and sitemap URLs.
  8. Scan public HTML, XML, and TXT output for IP literals, token-shaped strings, and sensitive paths.

This is the same habit behind my Coolify static site deploy checklist and the Docker Mailserver multi-domain checklist: separate the public web path from the mail path, verify each layer directly, and do not publish operational details that readers do not need.

Why this helps organic growth

DNS hygiene sounds like infrastructure housekeeping, but it supports discoverability. Search engines, feed readers, social previews, and humans all need one stable public URL. A site that flips between apex, www, staging, and old hostnames splits signals and makes debugging harder.

A clean Cloudflare and Coolify setup gives each useful page a stable home. That is not a traffic hack. It is the quiet foundation that lets practical posts, build logs, and project pages earn real visitors over time.

// keep reading

Related build notes