Why We Don't Put Cloudflare In Front Of Your Site

Short answer: Cloudflare changes what your server writes down about its visitors, and what your server writes down is half of what you are buying from us. There are good reasons to run Cloudflare. On the way we build, none of them pay for what it costs us.

The fifth grade version

Imagine your website is a shop. By the front door there is a notebook. Every single time somebody walks in, the notebook writes down where they came from.

Cloudflare is like hiring a doorman. He stands outside, meets everybody first, and then walks them in himself. He is genuinely good at the job. He can turn away troublemakers before they reach the door, and he keeps copies of your flyers out front so people do not have to wait for you to fetch one.

Here is the catch. Because the doorman walks everyone in, the notebook stops recording where visitors came from. It writes down the doorman instead. Over and over. Thousands of times a day.

For most shops that is fine, because nobody ever reads the notebook.

We read the notebook. Reading the notebook is the product.

What Cloudflare actually is

Cloudflare sits between your visitors and your server. Your domain name points at Cloudflare instead of at your host. Cloudflare answers the request, decides what to do with it, and passes along the ones it likes.

That position lets it do four useful things: issue an SSL certificate so the browser shows a padlock, cache your files in data centers near your visitors so pages load faster, absorb attacks before they reach your server, and filter requests through a firewall.

All four are real. They are worth having when you need them. The question is not whether Cloudflare works. It is whether you are paying a cost you have not noticed for a benefit you already have.

The four reasons people add it, and what we do instead

1. Free SSL

This is the most common reason, and it stopped being a reason years ago.

Our servers issue certificates automatically through Let's Encrypt. No configuration, no renewal reminders, no expiry surprise. Here is a live one from a client domain we set up recently, read straight off the server:

issuer:  Let's Encrypt
valid:   Aug 28 2026 through Nov 26 2026
covers:  the domain, www, plus mail and webmail subdomains
renews:  automatically, unattended

Nobody touched that. Nobody will have to. Adding Cloudflare to get an SSL certificate is solving a problem the hosting layer already solved, and it introduces a new one: proxied domains are a recurring cause of failed certificate renewals, because the renewal check has to reach your actual server and the proxy is in the way.

2. Speed

A content delivery network makes a slow site faster by storing copies of it closer to the visitor. It is a real fix for a real problem.

The problem it fixes is one our architecture does not create. The sites we build are flat files. There is no database to query, no plugin chain to load, no template engine assembling a page from a dozen lookups. A request arrives, PHP reads a JSON file, and the page goes out. The work a CDN is designed to hide is work we never do in the first place.

Caching something that is already fast mostly adds a place for it to go stale.

The honest exception: if you serve large media to a genuinely global audience, a CDN still helps, and physics is not negotiable. A visitor in Singapore is far from a server in North America no matter how fast that server is. That is a real case. It is not most cases, and it is not the reason most sites have Cloudflare turned on.

3. DDoS protection

This one is legitimate, and we want to be careful not to wave it away.

If you are actually being attacked, Cloudflare is very good and you should use it. What we push back on is adding it preemptively to a site nobody has ever attacked, in exchange for a permanent cost to your data. Buy the insurance when there is something to insure.

Worth separating two things that get blurred together here. Attack traffic is not the same as noisy automated traffic. In our own portfolio logs for the current retained window, automated scanners accounted for 2,445,548 requests. Every one of them got a cheap 404 or a block from the server and cost essentially nothing. Noise is not an attack. Our servers are already fine with noise.

4. Hiding your server's address

Real, and minor. It matters if someone is specifically hunting your origin server. For a business site, it is a footnote.

The part that actually costs us: the notebook

Here is where it stops being a preference and becomes an architectural decision.

Our data intelligence layer reads raw server logs. Not analytics JavaScript, which only fires for humans running a browser with scripts enabled. The actual request log, which records everything, including every machine that never runs JavaScript at all.

That distinction is the whole point, because the machines are now most of the traffic. From our own portfolio in the current retained log window, 2026-08-09 through 2026-09-13, across 130 sites:

Look at the first column and the last row together. Humans were under 4 percent of requests. A conventional analytics tool would have shown you that 4 percent and called it your traffic.

Every classification in that table starts from the IP address.

We resolve each address to the network that owns it. Our lookup table currently spans 12,620 distinct autonomous systems across 214 countries. That resolution is what lets us tell the difference between a crawler and something wearing a crawler's name.

Here are the networks the AI crawler traffic actually came from in that window:

Notice the bottom two. OVH and IONOS are commodity hosting companies. They do not operate AI crawlers. Something sending requests from a rented server there while announcing itself as a major AI crawler is not that crawler, and knowing which is which is the difference between a good bot and someone borrowing a good bot's name.

We can only make that call because we have the real address.

What a proxy does to that

When a full proxy sits in front of the site, the address your server records is the proxy's edge server, not the visitor. The original address moves into an HTTP header.

We want to be straight about this rather than overstate it: the data is not hidden from you. The real address is right there in the header, and there is a well-documented Apache module that reads it back into the log. This is a configuration burden and a silent-failure risk, not a conspiracy.

But those two things are exactly what we design against. It has to be configured correctly on every site. And when it is wrong, nothing breaks. No error, no alert, no red page. Your logs keep filling up, your reports keep generating, and the numbers quietly stop being true. Traffic from 146,430 distinct addresses starts collapsing toward a much smaller set of proxy ranges, and every classification downstream of it degrades in step.

A system that fails loudly is a bug. A system that fails quietly while still producing confident output is a considerably worse problem, because you act on it.

So the trade looks like this. We would take on a permanent configuration dependency, on every site, with a silent failure mode, in order to solve an SSL problem we do not have, a speed problem our architecture does not create, and an attack problem most sites never encounter.

We would rather not.

When we would absolutely use it

To be clear, because "we don't use X" is easy to mistake for "X is bad":

• You are genuinely under attack. Turn it on. Today. We will help.
• You serve heavy media to a global audience. The distance is real and a CDN is the right tool for it.
• You have a compliance requirement for a managed web application firewall. That is a requirement, not a preference, and requirements win.

In any of those cases we would add it, restore real visitor addresses at the server, and then verify that our classification still produces the same answers it did before. Deliberately, with the check written down. Not switched on and assumed to be fine.

So what does this change for you?

Three things.

Your numbers are the real numbers. When we report that a particular AI crawler read 400 of your pages last month, that is counted from your server's own record of the request. Not inferred, not sampled, not attributed to a proxy.

There is one less thing between you and your site. Fewer moving parts is not a slogan here. Every layer is a layer that can be misconfigured, expire, or fail in a way nobody notices for a quarter.

You can check our work. The logs are on your server. The classification rules are written down. If you want to know why a request was labeled the way it was, the address, the network, and the rule are all still there to look at.

One caveat we will keep repeating, because it is the real limit of this approach: log ingestion requires access to the server. That is a genuine constraint, and it is exactly why the sites we build live where we can read them. And it only ever tells you what a machine read. What any AI subsequently does with what it read is not something a server log can observe, and we will not pretend otherwise.

Reading the notebook only works if there is a notebook, and if the notebook says what actually happened.