Why I Chose Cloudflare

When I started putting the Eldritch IT websites together, I did not want a separate provider for every piece of public infrastructure.

I needed authoritative DNS, public HTTPS, a deployment path tied to source control, basic edge controls, useful logs, and room to add features later. I also wanted one architectural boundary to stay very clear:

the public websites should not depend on my homelab being healthy.

Cloudflare fit that requirement set well enough that I could keep the public path relatively boring while still having room to learn and expand.

That is the reason I chose it.

Not because Cloudflare is automatically the best answer for every site, and not because putting several products behind one account removes the need to understand them.

The platform reduced operational sprawl for this particular job.

The decision contract came before the platform

The original version of this article mostly described the parts I liked after deployment. If I were recording the decision today, I would start with the requirements.

Requirement	Why it mattered	What counted as enough
Central DNS management	Two public domains already created enough records and dependencies to become messy	One authoritative DNS view with clear record ownership
Public HTTPS	Certificate renewal should not become recurring manual maintenance	Managed edge certificates for proxied public hostnames
Source-controlled deployment	The repository should remain the source of truth for Field Notes	A Git-connected build/deploy path with visible failure logs
Public/homelab separation	A server reboot or lab mistake should not take down the public site	Public delivery hosted outside my home infrastructure
Low initial operating cost	Eldritch IT was still being built	A launch path that did not require a pile of subscriptions before revenue
Useful diagnostics	Failed builds and DNS mistakes should leave evidence	Logs and deployment state I could inspect instead of guessing
Room to grow	I did not want an immediate migration when requirements expanded	A path to Workers and other edge features without rebuilding the whole public stack

There were also things I did not need.

I did not need a traditional virtual machine just to serve Field Notes. I did not need to run my own public reverse proxy from the house. I did not need a separate vendor for certificates simply because certificates can be purchased separately. I did not need the deepest possible edge-compute feature set on day one.

Those boundaries kept the decision from turning into a product shopping exercise.

The alternatives were valid; they optimized for different things

Cloudflare was not the only workable architecture.

This comparison is intentionally about approaches, not a claim that every provider in a category behaves identically.

Approach	What appealed to me	What made it less attractive for this deployment
Registrar DNS + separate hosting/deployment provider	Clear separation of responsibilities and broad provider choice	More control planes and more places to correlate DNS, TLS, and deployment state
Dedicated static-site / application platform	Strong developer workflow and simple hosting	DNS and edge policy would still remain somewhere else unless I intentionally consolidated them
Self-hosting from the homelab	Maximum control and excellent learning value	Couples a public business property to home power, networking, maintenance, and experiments
Cloudflare	DNS, edge TLS, Git-connected deployment, public delivery, and future edge features in one ecosystem	More ecosystem dependence and another abstraction layer I still have to understand

The important part is that Cloudflare did not win every possible criterion.

It won the combination I cared about: keep the public websites independent from the lab, keep the deployment path observable, and avoid creating several small infrastructure chores just to publish a site.

If my main objective had been learning public web hosting from first principles, I could have chosen differently.

DNS was the first reason

Cloudflare entered the architecture as the authoritative DNS provider.

Both Eldritch IT domains could be managed in one place, records were easy to review, and the proxy state of web records was visible alongside the DNS configuration.

That last part matters because DNS-only and proxied records are not the same path.

A DNS-only record tells clients where to connect directly. A proxied web record places Cloudflare in the request path and enables Cloudflare’s edge behavior for that hostname.

That means I do not treat the orange-cloud toggle as decoration.

For every public record, I want to know:

• what service owns the hostname;
• whether the hostname should be proxied;
• what happens if the proxy state changes;
• whether another service, such as mail, depends on related DNS records;
• whether the record is still required at all.

Between the business site, Field Notes, email-related records, verification records, and other services, DNS can become messy faster than expected.

One dashboard helps.

Documentation still matters more.

Edge HTTPS removed one recurring task, not every TLS decision

I did not want public certificate renewal to become another manual maintenance process.

Cloudflare’s Universal SSL currently issues and renews publicly trusted edge certificates for activated Cloudflare zones, and proxied hostnames can present those certificates to visitors without me purchasing and rotating a separate public certificate for each site.

That solved the visitor-to-Cloudflare edge side of the problem for my public web path.

It does not mean TLS suddenly has only one boundary.

If Cloudflare is proxying to an origin, the origin connection still needs an intentional security model. A DNS-only hostname is also outside the protection of Cloudflare’s edge certificate presentation and must handle its own HTTPS path.

That distinction is important because “Cloudflare handles HTTPS” is too broad a sentence to be operationally useful.

The more accurate statement is:

Cloudflare removed manual public edge-certificate renewal from the jobs I wanted to own, while origin and DNS-only TLS decisions remained mine.

That is exactly the kind of managed-infrastructure trade I wanted.

Deployment became part of development

Field Notes is connected to GitHub and deployed through Cloudflare when the production branch changes.

That makes the repository the source of truth for the site code and content.

I can update an article or component, commit the change, and use the build/deployment result as evidence about whether Cloudflare could actually build what I gave it.

The workflow has already caught real mistakes.

When I added dynamic topic pages, a build failed because a helper used by getStaticPaths() was not available the way I expected after bundling. The build output identified the route and missing function, which gave me something concrete to fix.

A quieter mistake was just as important: Astro’s canonical site URL still pointed to example.com. The pages loaded, but the sitemap and canonical metadata would have advertised the wrong domain.

Cloudflare deployed the project it received.

It could not know what I intended.

That is why a successful deployment and a correct site are two different claims.

A green build proves the build/deploy path succeeded. It does not prove the canonical URL is right, every route exists, metadata is correct, or the rendered page does what I meant.

That lesson shows up throughout Building eldritchit.me with Astro.

The deployment model is clearer now than it was when I started

One source of early confusion was understanding where Pages ended, where Workers began, and which product owned the build and deployment behavior I was looking at.

Cloudflare’s current platform makes that relationship easier to describe.

Workers Builds supports direct GitHub and GitLab integration and can automatically build and deploy a Worker when commits reach the configured repository/branch. Cloudflare Pages also continues to support Git-connected deployments and preview builds for Pages projects.

Those are related deployment products, not interchangeable names for the same thing.

For me, the useful lesson is not memorizing the dashboard taxonomy.

It is recording the actual deployment contract for the site:

Source of truth: GitHub repository
Production trigger: production-branch change
Build command: project-defined
Deployment target: Cloudflare project
Configuration sources: repository + Cloudflare environment/settings
Validation: build result + public-site checks
Rollback/recovery: preserve known-good source and deployment history

If I can write that contract down, the product labels become much easier to reason about.

Managed public delivery keeps the site out of my garage

I enjoy maintaining servers in my homelab.

That does not mean every public service should depend on them.

A business-facing site should not disappear because I rebooted a host, changed a firewall rule, broke an unrelated container stack, lost home internet, or decided to rebuild part of the lab on a Saturday night.

Keeping public delivery outside the homelab gives the website a different failure domain from the systems I intentionally experiment with.

That separation is more important to me than the novelty of self-hosting the site.

Field Notes currently uses Astro with Cloudflare’s platform integration, which gives me a path to Workers capabilities when the application needs them without requiring me to operate a traditional public web server.

That was one of the core stack decisions for eldritchit.me.

Low initial cost mattered, but it was not the architecture

Cost mattered because Eldritch IT was still being built.

I did not want the website stack to accumulate subscriptions before the business had clients.

Cloudflare’s free offerings were sufficient for the requirements I had at launch, which made the initial decision low-risk.

But “it was free” is not enough of a reason to build around a platform.

Pricing, quotas, included features, and product packaging can change. The architecture still needs to make sense if a future requirement pushes part of the stack into a paid tier.

The question I care about is:

If the site becomes valuable enough to exceed the free path, would I still be comfortable operating this architecture?

For this project, the answer was yes.

That is a much stronger reason than treating a free tier as permanent infrastructure policy.

Consolidation created a larger dependency too

Putting DNS, edge TLS, deployment, and public delivery into one ecosystem reduced the number of systems I had to operate.

It also concentrated more responsibility in one provider.

That is the tradeoff.

If Cloudflare has an account, configuration, deployment, or platform problem that affects the services I use, several parts of the public path can be involved at once.

So consolidation changes what I need to preserve independently.

I care more now about:

• keeping the source repository authoritative and recoverable;
• documenting DNS intent rather than trusting the dashboard as institutional memory;
• knowing which hostnames are proxied and why;
• preserving configuration and environment-variable ownership;
• understanding how I would move DNS or deployment if the platform stopped fitting the requirement;
• keeping registrar/account recovery separate from day-to-day site administration where practical.

Convenience is useful.

Exit knowledge is part of the architecture too.

A small failure matrix keeps the platform honest

One reason managed platforms become confusing is that very different failures can all look like “the website is down.”

I now separate the likely boundaries before I start changing settings.

Symptom	First boundary to prove	What I would avoid assuming
Domain does not resolve	Authoritative DNS and record state	That the application build is broken
DNS resolves but HTTPS fails	Proxy state, edge certificate state, hostname configuration	That GitHub or Astro caused the problem
Build fails after a commit	Build log, dependency/configuration state, project command	That public DNS changed
Build succeeds but content is wrong	Rendered output, canonical URL, route/content logic	That Cloudflare should infer application intent
Production site is old	Deployment history, production branch/trigger, build status	That browser cache is automatically the cause
One hostname works and another does not	Per-hostname DNS/proxy/certificate/configuration state	That the whole Cloudflare account is down

That table is more useful than treating Cloudflare as one giant box.

DNS, edge TLS, build execution, deployment, application output, and browser-visible behavior are separate proof points even when one vendor provides several of them.

It is not frictionless

Cloudflare has a large product ecosystem, and the naming can still be confusing when a project crosses product boundaries.

Workers, Pages, Builds, bindings, environment variables, routes, domains, DNS proxying, and deployment configuration are distinct concepts even when the dashboard places them close together.

The platform automates a lot.

It cannot decide what the site is supposed to be.

It cannot know that my canonical URL is wrong if the application successfully builds it that way. It cannot tell me whether a DNS exception still has a business reason to exist. It cannot decide which environment variable belongs in source control and which belongs in protected configuration.

Managed infrastructure still needs an owner.

When I would choose something else

A decision record should include the conditions that would change the decision.

I would reevaluate the Cloudflare-centered approach if the project needed capabilities that fit another platform materially better, if product or pricing changes made the ownership model unattractive, if a customer requirement imposed a different hosting/compliance boundary, or if reducing provider concentration became more valuable than the current operational simplicity.

I would also choose differently for a project whose purpose was specifically to learn traditional public web-server operations.

Cloudflare fit because operating the public web server itself was not the problem I was trying to solve.

What I would do differently

I would write the deployment and DNS contracts before configuring the first site.

For deployment, I would record:

• source repository;
• production branch;
• build command;
• deployment command/target;
• environment-variable ownership;
• custom-domain ownership;
• validation steps;
• rollback expectations.

For DNS, I would record:

• hostname;
• record type;
• service owner;
• proxy state;
• purpose;
• removal condition.

I would also verify the canonical site URL, sitemap output, production domain, build/output mode, and public routes before treating the first green deployment as finished.

The biggest improvement would not be a different provider.

It would be better documentation of the contract between GitHub, Astro, Cloudflare, DNS, and the public site.

Currentness note

The Cloudflare-specific claims in this article were reviewed on September 14, 2026 against current Cloudflare documentation.

At that point, Cloudflare still documented Universal SSL as automatically issued and renewed for activated zones, with edge certificate presentation tied to proxied hostnames. Workers Builds supported direct GitHub/GitLab integration with automatic deployment on push, while Pages continued to support its own Git-connected deployment workflow.

Those are current platform details, not timeless architecture. Cloudflare product names, limits, plans, and deployment workflows can change, so a future implementation should recheck the current upstream documentation before copying this design.

Current references

• Cloudflare Universal SSL
• Cloudflare Universal SSL limitations
• Cloudflare Workers Builds
• Cloudflare Workers Git integration
• Cloudflare Pages Git integration

AI transparency

AI assisted with code review, troubleshooting direction, current-documentation verification, decision-matrix design, and editing this article. The platform choice, configuration work, historical build failures, DNS experience, and conclusions are based on my experience deploying the Eldritch IT websites. The September 14, 2026 revision distinguishes current Cloudflare product behavior from the original deployment experience instead of rewriting the historical setup as though the platform never changed.