“What are the alternatives to Cloudflare?” is one of the most-asked questions in delivery procurement, and one of the least useful as stated. Cloudflare is four products in a trench coat — DNS, delivery, security and a developer platform — and a replacement for one of them is rarely a replacement for the others. The productive version of the question is which of the four is failing you.
Ask which product is failing, not which vendor replaces it.
Teams leave Cloudflare for four reasons: the per-zone plan ladder, the enterprise price step, the content-type terms on self-serve plans, and concentration risk. Only two of those are actually solved by a different vendor. The other two are solved by reconfiguring what you already have, or by adding a second provider rather than swapping the first.
Reason one: the plan ladder stopped fitting
Cloudflare’s self-serve pricing is per zone, and it has been remarkably stable — roughly $25 and $250 a month at monthly billing, about a fifth less annually, with a free tier that remains the most generous in the industry. The model works beautifully for one or two important domains and badly for a portfolio, because there is no self-serve volume discount: the fortieth zone costs exactly what the first one did. Agencies, holding companies and any business with a long tail of brand domains hit this first.
The step from the mid tier to enterprise is the other pressure point, an order-of-magnitude jump with no rung between. Practical entry to a negotiated contract sits in the low thousands per month, which is correct for a large estate and absurd for a company that needed one feature from the higher tier. The gap is real, and it is the single most common reason a happy customer starts shopping.
If this is your problem, the answer is usually not migration. It is auditing which zones genuinely need a paid plan — most portfolios are paying for tiers on domains that redirect — and then pricing a consolidated contract against a specialist quote to see whether the negotiated number is competitive. Where the paid features you need are narrow, per-GB providers with all features included on every account will undercut it substantially, which is the case made in Cloudflare versus bunny.net.
Reason two: your content type is the problem
Unmetered bandwidth is the reason Cloudflare feels free, and the self-serve agreement has always constrained it: using the service primarily to serve video or other large non-HTML files is outside the terms. Most sites never approach that line. Media libraries, download mirrors, game asset delivery and video platforms sit on the wrong side of it by construction, and the resolution is a negotiated contract or a different provider.
This is the cleanest case for leaving, and the market answer is a metered specialist. Per-gigabyte delivery at a cent or below in cheap regions turns large-file delivery into a small, predictable line, and the providers built for it treat video and installers as the normal case rather than an exception — the field is surveyed in budget CDNs under a cent. The trade is that you assemble security separately, which is only a downside if you were relying on the bundled version.
Do the arithmetic before the migration, not after. Metered delivery of a genuinely large library can also be the more expensive answer if your audience sits in premium regions, and region-weighted pricing punishes dispersion. Model your real regional mix rather than the headline rate.
Reason three: you need a feature that lives on the wrong tier
A recurring pattern: a team needs one capability — bring-your-own certificates, keeping their existing authoritative DNS rather than delegating nameservers, granular rate limiting that counts on something other than address, or contractual uptime commitments — and finds it two tiers up. That is a feature gate, not a capacity limit, and it is why the ladder feels punitive to engineers: the network serving your bytes is the same one on every plan.
Here the honest answer is frequently to stay and pay, because the alternative — running delivery somewhere else while keeping DNS and security where they are — adds an integration seam for a single feature. But two of these specifically justify leaving. If you cannot delegate nameservers for organisational or technical reasons, providers that have always worked by aliasing are structurally easier. And if you need a contractual service level, buying from someone who sells one at your spend level beats buying a tier you otherwise do not want.
Before either, check whether the feature is genuinely unavailable or merely unfamiliar. A surprising share of “we need enterprise” conversations resolve into a rules configuration nobody had written, which is the cheapest possible outcome.
Reason four: concentration risk
The fourth reason is the one that has grown fastest, and it is not a complaint about the product. When authoritative DNS, delivery, security and increasingly application code all terminate at a single provider, your exit is a project rather than a hostname change, and your availability is correlated with one company’s worst day. Large outages at any major provider make this argument for you every time one happens.
The answer to concentration is not usually a swap, because the replacement creates identical concentration under a different logo. It is deliberate separation: authoritative DNS at an independent operator so steering stays portable, a second delivery path configured and periodically exercised, and configuration held in code so it can be reproduced elsewhere. That is the architecture in designing a multi-CDN architecture, and the DNS half in the managed DNS comparison.
Sovereignty pressure is a variant of the same argument arriving through procurement rather than engineering. European buyers increasingly need jurisdictional answers that a US-headquartered vendor cannot give regardless of where the bytes are cached, which pushes them toward EU-owned providers for specific workloads — not necessarily for all of them.
What the shortlist actually looks like
Sorted by the problem being solved rather than by market share: for metered large-file delivery, the per-gigabyte specialists. For enterprise security depth and in-network reach, the incumbents. For real-time configuration control and a programmable edge, the developer-centric networks. For Asia-Pacific and mainland China, the regional specialists, because no western network solves that with a checkbox. For European jurisdiction, the EU-owned providers. Several of those categories overlap, and the right answer for many estates is two providers with different jobs rather than one replacement.
Whatever the shortlist, test before you commit. Run the candidate on real traffic, from your real audience geographies, measuring cache hit ratio and tail latency rather than a synthetic average — the discipline is in benchmarking CDNs fairly. And price the whole stack, not the delivery line: a lower per-GB rate that arrives with a separate WAF bill is not automatically cheaper.
The uncomfortable conclusion
For most sites, Cloudflare remains extremely hard to beat on value, and the honest advice is to fix the configuration rather than change the vendor. The exceptions are specific and identifiable: heavy non-HTML delivery, portfolios paying per-zone for dozens of domains, requirements that live behind a tier you do not otherwise want, and estates that have concentrated so far into one provider that the concentration is itself the risk. If your reason is not on that list, the migration will cost more than it returns — and if it is, you now know which shortlist to build.