Cloudflare answers your visitors before your server ever hears from them.
Somebody has suggested putting your site behind Cloudflare, probably after an attack, a slow week, or a certificate that expired on a Sunday. It is usually good advice and it is rarely explained.
What you are agreeing to is a change of address. Your domain stops pointing at your server and starts pointing at Cloudflare, who then decide what reaches you. That is where the speed and the protection come from, and it is also why the account matters more than the settings.
Cloudflare is a network that sits between your visitors and your server. Your domain points at them, so every request arrives there first. They can answer it from a copy held near the visitor, block it, slow it down, or pass it through to you. They also handle the certificate that puts the padlock in the address bar.
Where it earns its place.
What it actually does
Four jobs. It is worth knowing which of them you are buying.
- DNS: the record that tells the internet where your site lives
- Caching: images, scripts and files served from a machine near the visitor
- Certificates: SSL issued and renewed without anybody remembering to
- Filtering: bad traffic, scrapers and floods stopped before they cost you anything
What we set up
On most business sites this is an afternoon. Half of it is checking that nothing quietly broke.
- The DNS records moved across exactly, including mail
- SSL end to end, so the connection to your server is encrypted too
- Caching rules that leave logged-in pages alone
- Rate limits on the login and the enquiry form
- The origin server locked so it only accepts traffic from Cloudflare
Moving DNS without a dark hour
People are right to be nervous about this one. Done in order, nobody notices.
- List records
- Lower TTL
- Import
- Compare
- Switch
- Watch
- Every existing record written down, from the old provider, before anything changes
- Mail records checked twice, because a missing MX record is the classic disaster
- The import compared line by line against the list, not trusted
- The switch made when your office is awake and not on a Friday evening
What it does not do
Said plainly, since it gets sold as a cure for things it has never touched.
- It does not make a slow database query fast
- It does not back anything up
- It does not tell you your site is down, unless monitoring is set up separately
- It cannot cache the pages that are different for every logged-in person
If your application is slow because of what it does on the server, a cache in front of it moves the problem rather than solving it.
Who should own the account
This is the part of the page we would keep if we had to cut the rest.
- The account is opened on an email address the business controls
- Your own people hold the login, and the developer gets access under it
- Domain registrar details kept somewhere other than one laptop
A domain held hostage by an old agency, or a site dark because the only login belonged to somebody who left. Neither of those is a technical problem.
When this is the right choice.
- A public site or portal that gets traffic from outside your office
- Certificates that have expired at least once and caused a bad morning
- A login page being hammered by attempts from nowhere near your customers
- Visitors outside your own region, who are far from wherever the server sits
- DNS currently spread across a registrar, an old agency and a hosting panel
When it is not.
- An application that is slow because of its own queries, where a cache in front hides nothing
- An internal system reachable only on your own network, which gains nothing from a public network in front
- A setup where the vendor opens the account in their own name, because your domain effectively becomes theirs
- Standing in for backups, monitoring or a security review, none of which it does
Questions we are asked about it.
Do we need a paid plan?
Most small and medium businesses start on the free level and stay there for a long time. What pushes an upgrade is usually a need for custom firewall rules, image handling, or a support channel you can escalate to during an incident. We will tell you when you have reached that point.
Will moving DNS break our email?
Only if the mail records are missed, which is the commonest way this goes wrong. Your MX records and the related verification records have to move across with the rest. We list them first, compare after, and send a test mail both ways before calling it done.
Does it make our website faster?
For images, scripts and anything that can be copied, noticeably. For a page built fresh for each logged-in person, it changes little, because that page still has to come from your server. Both are worth knowing before you judge the result.
Is our site safe once it is behind Cloudflare?
Safer against floods, scrapers and blunt attacks. Not safe against a weak password, an unpatched plugin, or a permission your application never checked. It is a wall in front of the building, not a lock on every door inside.
Can you set it up on a site you did not build?
Yes, and it is often the first thing we do when taking over an application. We need access to the domain registrar and to the current DNS. If nobody knows where the domain is registered, finding that out is the first job.
Can we move away from it later?
Yes. The DNS records can be pointed back, and the only work is reversing the parts that depend on it, such as origin rules and certificates. Nothing about your application is written for Cloudflare, which is one reason we keep it that way.
Services that use it.
What it sits with.
Not sure Cloudflare is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private