Cloudflare
The control plane I use for DNS, edge delivery, redirects, email routing, and lightweight deployments.
Why it earns a place
Why I use it
It collapses several boring but essential jobs into one place: authoritative DNS, proxying, redirects, Pages/Workers, security controls, analytics, and email routing. I use it when I want fewer moving parts around a domain.
Use cases
Best for
- Putting DNS and edge controls in one account
- Hosting small Astro/static tools close to users
- Creating redirect rules without shipping a new app build
- Receiving mail on a custom domain without buying another mailbox
Start small
Quick start
- 01Move DNS first
Add the domain to Cloudflare, copy the assigned nameservers into your registrar, then verify that the zone becomes active before changing production records.
- 02Connect the app
Create a Pages project from GitHub, use the framework preset for your app, then attach the custom domain after the first successful deploy.
- 03Keep records explicit
Use DNS records for web, mail and verification separately. Avoid changing MX, SPF, DKIM or DMARC records casually when you are only trying to move the website.
Repeatable workflows
Things I come back for
Email Routing
Create a destination address, verify it, add a custom address on your domain, and let Cloudflare install the required MX records. Pair it with a transactional sender such as Resend when you also need outbound mail.
- 1
Open Email Routing and add the destination mailbox.
- 2
Verify the destination and create the custom address on your domain.
- 3
Let Cloudflare add the routing records, then send a real test from outside the domain.
Redirect Rules
Use a redirect rule for old paths, naked-domain canonicalization, or retired subdomains. Keep permanent redirects for URLs you genuinely want search engines to replace.
- 1
Write the exact source pattern and destination first.
- 2
Create the rule and choose permanent only when the move truly is permanent.
- 3
Test both the matching URL and a nearby non-matching URL before forgetting about it.
DNS debugging
Check whether a record is proxied, verify the target value, then use a public DNS lookup before assuming the application is broken.
- 1
Inspect the record type, hostname, target, and proxy state in Cloudflare.
- 2
Check public DNS resolution from outside your own browser cache.
- 3
Only then inspect the application or host if the DNS answer is correct.
Subdomains
Create one project per genuinely independent tool, then map subdomains such as image.bemorin.com or silence.bemorin.com to the corresponding deployment.
- 1
Deploy the independent tool first and obtain its host target.
- 2
Add the custom subdomain to that project.
- 3
Create or confirm the corresponding DNS record, then test HTTPS after propagation.
Reference