Cloudflare
Your site runs behind Cloudflare, and nobody explained what that does
The short answer
Cloudflare is a network your visitors reach before they reach your website. It answers your domain's lookups, keeps copies of your files close to people so pages arrive faster, and filters attack traffic on the way through. It also runs code and stores data now, which is a separate decision with different limits.
The name turns up in your domain settings, or in a proposal, and nobody explains it. Cloudflare is easy enough to switch on that plenty of sites ended up behind it without anyone treating it as a decision. It is one. Here's what it does to a request, and where it stops.
It sits in front of your site, not underneath it
Cloudflare is usually not where your website lives, which is what most explanations skip. The site runs somewhere else, on hosting somebody signs into, and that place has a name here: the origin. Cloudflare goes in front, and every visitor passes through on the way.
You get there by pointing your domain at Cloudflare's name servers. From then on the lookup that finds you is answered by Cloudflare, and the request lands at the nearest location on a network it puts in hundreds of cities.
Three jobs happen in that one place, and most businesses buy all three without separating them. It answers DNS, the lookup that turns a name into an address. It holds copies of your files. And it inspects what comes through.
01
Visitor asks
A browser looks up your domain. Cloudflare answers, and points the request at its closest location.
02
Nearest location
The request lands near the visitor, not near your server. Attack and bot checks happen here.
03
Copy or origin
If a copy is held there it goes straight back. If not, Cloudflare fetches it from your server.
04
Page arrives
The visitor gets the response. Your server never saw the requests answered from a copy.
Why a copy nearer the visitor makes a site feel faster
Most of the waiting on a web page is travel, not work. A request from Vancouver to a server in Frankfurt makes that trip several times before anything appears, and tuning the server doesn't shorten the distance.
A content delivery network shortens the distance instead. It keeps copies of the parts of your site that are the same for everybody, images, stylesheets, fonts and scripts, close to the people asking. Nothing about your server got faster. The trip got shorter. Other providers do the same job, and the differences show up in the filtering and the code platform rather than here.
One detail catches people who expected magic. Cloudflare caches by file extension, and HTML pages aren't on the default list, so images and scripts are cached the moment you switch it on while the page itself still comes from your server.
The protection is real and narrower than it sounds
Attack traffic is the other reason most sites end up here. A denial-of-service attack isn't clever. It's a great many machines asking for your site at once until nothing is left for real people, and surviving it takes more spare capacity than the attacker has.
Layered on that are a firewall that blocks requests matching known attack patterns, rate limiting that stops one source hammering your login form, and bot management that tries to tell a search engine's crawler from a scraper wearing its name.
What none of it touches is your own software. A reused password, an admin account with no second factor, an abandoned plugin with a hole in it. Cloudflare filters traffic. It doesn't audit what your application does with what gets through.
Then it became a place to run things
For years that was the whole product. Then Cloudflare started letting people run their own code in those same locations, which turns it from a setting on your domain into a hosting choice.
The code product is called Workers. A piece of your application runs at whichever location the visitor arrived at, rather than on one server in one region. Storage grew up around it: files, a key-value store, a database, and a coordination layer for things that need one authoritative copy. The appeal is that there's no machine to keep patched.
The vocabulary gets slippery here. Cloudflare ships fast and folds products into one another, so a proposal written a year or two ago can name something since renamed or absorbed. Look any named product up in the current documentation.
Where the edge model stops
Running code at the edge isn't renting a server with fewer steps. Each piece is expected to start quickly, do a bounded amount of work and finish. There's a ceiling on processing time per request, a small memory allowance, and nothing written to disk survives it. Long jobs, video encoding, an overnight process: those don't fit.
The runtime isn't a full operating system either. It runs JavaScript first and other languages through compatibility layers, so a library that assumes a conventional server can fail once real traffic hits it. Reaching a traditional database from hundreds of places is its own problem.
Then there's what moves. Your code and files do. The coordination layer and the edge database are Cloudflare's own designs with no equivalent elsewhere, so an application built on them stays. That's a fair trade made knowingly and an unpleasant surprise made by accident.
Code at the edge
A conventional server
- Where it runs
Code at the edge: Near whoever asked, but you never pick or log into the machine.
A conventional server: In one region you chose, close to the database and far from many visitors.
- What it will run
Code at the edge: JavaScript first. Some libraries never work at all.
A conventional server: Anything the operating system runs, and you patch all of it.
- Heavy or long work
Code at the edge: Bounded time and memory per request. Long jobs need another product.
A conventional server: Runs as long as you let it, on a machine you pay for idle.
- Getting back off it
Code at the edge: Code and files move. The coordination layer and database have no equivalent.
A conventional server: Runs on any other server, and moving it is still a project.
Who has to be available, and what a bad day looks like
The staffing answer differs between the two halves of this. Cloudflare in front of an ordinary website needs almost nobody: somebody sets it up, and somebody understands the caching well enough to clear it when a change doesn't appear.
Workers is a different question, because the platform is then where your software lives. You need somebody who knows this platform specifically rather than a developer who knows servers, and a team new to it learns on your budget.
Then there's concentration. W3Techs, which surveys what public websites run on, has put Cloudflare far ahead of every other service of its kind for years, and past outages have taken large parts of the web down together. That's not an argument against it, but for knowing whose name is on the account and what happens the day you turn it off.
Worth knowing before you start
Check whose email address the Cloudflare account is registered to, then check the registrar underneath it. Lose access to DNS and you lose the website, the company email and your proof that you own the name.
After a deploy, purge the cache before you start debugging why a change didn't appear. Hours get lost to a bug that turned out to be a stale copy sitting in front of a page that was already fixed.
Learn what the orange cloud in the DNS screen means. Each record is either proxied through Cloudflare or pointed straight at your server, one toggle apart, and an unproxied record publishes your server's real address.
Before anyone builds on Workers, ask which parts of the design would have to be rewritten to run elsewhere. If the answer is the database and the coordination layer, that can be reasonable, as long as somebody decided it.
Common questions
Usually not. It sits in front of hosting you already pay for and passes traffic through. It does sell hosting of its own now, so it can be both. Worth confirming which you have, because it decides who you call when the site is down.
For a lot of sites, yes. The entry tier covers what an ordinary site needs from DNS, caching and attack filtering, which is much of why it spread so widely. Paid tiers buy finer control. Plans change, so read the current plan page rather than an article about it.
Yes, and it has to. Inspecting and caching encrypted traffic means decrypting it on Cloudflare's network first. That trade is accepted across the industry and it's still a real one, so raise it deliberately if you handle health or financial records. Cloudflare offers controls over which regions do the decrypting.
Partly. It shortens the distance and takes load off your server. What it can't fix is a slow page: oversized images, a page assembled from too many database queries, a platform doing too much per visit. If your server takes four seconds to produce a page, it still takes four seconds.
Quite a lot, if your DNS lives there, because the lookup that finds you goes through them too. Sites behind it have gone dark together in past incidents. What helps is keeping a copy of your DNS records outside the account and knowing the change is reversible.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.