Cloudflare Pages Alternatives

Last month a reader emailed me a problem that had nothing to do with downtime and everything to do with deploy limits. His team runs a documentation site on Cloudflare Pages — the free plan, which I still think is one of the best deals in hosting anywhere. Then came a docs sprint: forty-odd merges in a week, each one triggering a build. Midway through week two, deploys started queuing behind each other, and a few flat-out failed. He had burned through most of the 500 builds the free plan allows per month, and because the free tier only runs one build at a time, every push stacked behind the previous one. Nothing was broken. The site was fine and the traffic was free. But the workflow that had pulled him onto Pages in the first place — push, build, live — had quietly turned into a bottleneck.

That is the thing about Cloudflare Pages: almost nobody leaves because of a renewal bill. There is no renewal bill to shock you. People leave because of build quotas, because the platform's roadmap is pointing somewhere else, or because their site stopped being a static site. In this guide I'll walk through when leaving actually makes sense, when it does not, and what I would move to instead — with honest pricing, including the parts of these platforms' billing models that catch people out.

When it makes sense to leave Cloudflare Pages

You are hitting the build ceiling

The free plan gives you 500 builds a month across the whole account, one concurrent build, and a 20-minute timeout per build (Cloudflare documents all of this in its Pages limits page). For a solo blog publishing twice a week, 500 builds is enormous. For a team doing trunk-based development where every merge to main triggers a production build — plus preview builds on every pull request — it disappears fast. In my experience a team of five or six active developers will chew through 400-plus builds a month without doing anything unusual.

The escape hatch is a paid Cloudflare plan: Pro raises the allowance to 5,000 builds a month and 5 concurrent builds, Business to 20,000. But those plans are billed around a domain, and if you host a portfolio of small sites the economics get silly quickly. This is the first genuinely common reason to look elsewhere.

The roadmap is pointing at Workers

Cloudflare's own Pages documentation now tells new projects to start on Workers with static assets instead. Pages is fully supported — nothing is being taken away from you — but the newer platform capabilities land on Workers first. If you want to be on the stack Cloudflare is actively developing, that means learning the Wrangler config model, the assets-and-Worker routing rules, and the bindings system. Some people enjoy that. Many people who chose Pages precisely because it was a simple static host do not. If the platform's direction is making you uneasy, that is a legitimate reason to evaluate alternatives while your site is still small enough to move cheaply.

Your site stopped being a static site

Pages Functions run on the Workers runtime, and their requests draw from the same free quota as everything else on your account — 100,000 requests a day on the free plan, which sounds generous until a popular page triggers a function on every load. There is no built-in forms product: a contact form means writing a function. Authentication means reaching for Cloudflare Access or a third party. Databases mean D1, KV, R2, Durable Objects — all good products, all deepening your investment in one ecosystem. If you have a site with a real backend in its future — a membership area, an online store, background jobs — you may be better off on a platform built around long-running services rather than edge invocations.

Support has become the bottleneck

On the free tier, support is community-forum support. That is fine until it is not: an account-level suspension, a billing question, or a build system issue that only Cloudflare can see will not get answered by a volunteer. If this site pays your rent, and a bad week costs you real money, a provider with a support team you can reach is worth paying for. Plenty of the alternatives below are worse than Cloudflare at raw network reach and better at picking up the phone.

When you should stay

Be honest with yourself before you migrate anything, because for a large category of sites Cloudflare Pages is simply the right answer and moving would be a downgrade.

Stay if your site is mostly static — a blog, docs, a marketing site, a portfolio — and traffic is unpredictable or growing. The free plan does not meter static asset bandwidth. I have had client sites on Pages absorb traffic spikes that would have triggered overage invoices on hosts that meter gigabytes, and the invoice was zero. (The terms of service do prohibit using it as a CDN for large binaries like video, so this is a static-site deal, not a free-for-anything pipe.)

Stay if price stability matters more to you than features. There is no introductory rate that triples at renewal here. Free is free, and the paid Workers tier starts at a flat $5 a month at time of writing with static asset requests still unmetered. Compare that to the shared-hosting world, where the first term is a marketing expense and the renewal is the business model.

Stay if you run a lot of small sites or a team. The free plan allows 100 custom domains per project and unlimited users, with automatic TLS and DDoS protection from the network underneath. I have migrated sites like the reader's docs project off Pages in an afternoon and back again a month later; sometimes the right move is to fix the workflow — fewer preview builds, a manual production deploy step — rather than the platform.

The alternatives

These are the options I would actually put in front of someone leaving Pages, drawn from the hosts we track in our database. Pricing is what I could verify at time of writing — always re-check the provider's own pricing page before you commit.

Netlify — the closest like-for-like

If what you want is simply Pages with a different logo, Netlify is the direct substitute: Git-push deploys, preview deployments on every pull request, atomic deploys with instant rollback, serverless and edge functions, custom domains with free TLS. Its build-plugin ecosystem — Lighthouse budgets, cache warming, sourcemap uploads — is deeper than anyone else's, and there is an actual forms product, which Cloudflare does not have.

The honest catch is the billing model. In September 2025 Netlify moved to credits: bandwidth, deploys, compute, and requests all draw from one pool. The free plan is a hard 300 credits a month, and at roughly 20 credits per GB of bandwidth that works out to something like 15GB of real traffic for a new account — not the 100GB Netlify was famous for. When the credits run out, the site pauses and shows an error page. Personal is $9/month for 1,000 credits and Pro is $20/month for 3,000 credits with unlimited team members, at time of writing. It is good value, but it is a metered model now, and a traffic spike drains credits fast.

Render — when the site is going to need a backend

Render is a general application host that happens to offer free static site hosting: CDN, managed TLS, Git-push deploys, preview environments. The reason to pick it is what sits alongside your frontend — web services, background workers, cron jobs, managed Postgres, Redis — all in one dashboard and one bill. If you are leaving Pages because the site is growing a real backend, this is the shape of platform you are growing into.

The trade-offs are specific. Static sites are free but their bandwidth counts toward the workspace: 5GB a month on the free Hobby workspace, pooled across every service, then $0.15/GB at time of writing. Free web services spin down after roughly fifteen minutes idle and take 30–60 seconds to wake up. Paid web services start around $7/month for the entry tier, and the Pro workspace adds $25/month on top of compute, at time of writing. Read the pricing page carefully — the bill is workspace fee plus resources, and people routinely mis-add those two numbers.

Railway — containers without the sysadmin work

Railway is where I send people who want to run an actual container — a Node API, a Python worker, a small database — without configuring servers. You push a repo or a Dockerfile, and it runs with per-PR environments and sane defaults.

Railway's billing deserves a clear warning, because it surprises people. The Hobby plan is $5 a month and that fee buys you $5 of usage credit — it is a floor, not a cap. Resources are metered beyond it (at time of writing: $20 per vCPU-month, $10 per GB of RAM-month, $0.05 per GB of egress). A small app plus a Postgres instance typically lands right around the credit; a busy one goes past it. Railway does let you set a hard usage limit that shuts workloads down when reached, which I recommend turning on immediately. Pro is $20 a month per workspace with a $20 credit and unlimited seats. There is a permanent free plan too, but at $1 of credit a month it is for experiments, not production.

Akamai Nanode 1GB — a flat-price Linux box

Sometimes the honest alternative to a managed platform is a small server you run yourself. The Akamai Nanode 1GB — the old Linode entry plan, now sold under Akamai Cloud — is 1 vCPU, 1GB of RAM, 25GB of SSD and about 1TB of transfer for $5 a month at time of writing. I have verified this one's renewal behavior specifically: it renews at the same $5. No introductory rate, no year-two jump. That kind of price honesty is exactly what HostingSpotter exists to track.

Put nginx or Caddy on it, add a small build script or a CI runner pushing artifacts over rsync, and a static site with generous room costs less than most platforms' coffee money. The cost is your time: you own the updates, the TLS renewal, the backups, and the pager. If you are comfortable in a terminal, this is the cheapest way to get out of anyone's platform roadmap entirely.

Kamatera — configure-it-yourself cloud with hourly billing

Kamatera is a build-it-yourself cloud in the same spirit, but with far more knobs: pick the CPU class, RAM, and NVMe storage separately across 20-plus data centers. The entry configuration — 1 vCPU, 1GB RAM, 20GB NVMe, 5TB of traffic — starts at $4 a month at time of writing, and because there is no introductory discount there is no renewal jump either. Billing can be monthly or hourly (roughly half a cent an hour for the entry size), which makes it genuinely useful for staging servers and test environments you tear down after a sprint. There is a 30-day trial worth up to $100 of usage, and a managed-service add-on around $50/month if you want humans handling the server. Watch the fine print: monthly servers bill the full month even if you cancel on day two, and traffic allowances shrink in the Asian data centers.

Liquid Web Cloud VPS — a VPS with support that answers

If the reason you are leaving is support rather than price, Liquid Web Cloud VPS is the pick. The entry cloud VPS — 1 vCPU, 1GB RAM, 30GB storage, 1–2TB transfer — lists at $5 a month at time of writing and, on the plans I checked, renews at the same rate. It is unmanaged at that price point; Liquid Web's fully managed VPS tiers are a different product with real prices attached (the managed line starts around $36 a month on the one-month plan and renews higher — the promo pricing there is exactly the kind of intro-then-jump we flag on HostingSpotter, so budget for the renewal number, not the banner). The appeal is the company behind it: known for support that picks up, 10 Gbps network, and a track record with mission-critical workloads.

Cloudways — a managed stack on someone else's cloud

Cloudways sits between raw cloud and traditional hosting: you get a DigitalOcean, Vultr, Linode, AWS, or Google Cloud server with the stack managed for you — staging, backups, free SSL, a control panel — billed hourly with no contract. That model has a real virtue for renewal pricing: there is no introductory discount, so there is no renewal shock. The entry DigitalOcean plan (1GB RAM) is listed at $14 a month on Cloudways' own pricing page at time of writing, though some older reviews still quote $11, so check the current page. The trade-off is the premium: you are paying Cloudways roughly half again over the raw cloud instance underneath, which is exactly what a Nanode or Kamatera comparison will show you. For WordPress or WooCommerce sites that need managed hosting without a sysadmin, the premium is usually worth it. For a plain static site, it is overkill.

For what it is worth, if data residency is your reason for leaving — you need everything in Australia, say — hosts like Web24 (from around $10 a month flat, Melbourne data center) and Over the Wire (from $20 a month, Brisbane and Sydney) both show zero renewal increase in our database, and neither will care about your build count because you will be managing the deployment yourself.

How to switch without downtime

I have done this migration more times than I can count, and the moves that actually prevent downtime are unglamorous preparation, not clever tooling. Here is the sequence I use.

Lower your DNS TTLs first. A day or two before the switch, drop the TTL on the records you will change to 300 seconds. If you skip this, you can make a mistake and wait hours to fix it.

Reproduce the build on the new host before changing anything. Connect the repo, run the same build command, and diff the output directory against what Pages serves today. Most "migration downtime" is actually a broken build that only reveals itself after the DNS flips. Copy across every environment variable, and check for Pages-specific behavior — _headers, _redirects, Functions routes, image transformations — and rebuild each of those in the new platform's idiom. Netlify has direct equivalents for redirects and headers; on a VPS it is your web server config; on Render or Railway it is application code.

Deploy to a staging URL and test it properly. Check the homepage, a deep link or two, a form submission, 404 behavior, and HTTPS. Do this against the staging hostname the new host gives you, not against your imagination.

Then cut over. Point the CNAME or A record at the new host, and leave the Cloudflare Pages project running untouched for at least 48–72 hours. Old caches, slow resolvers, and email clients with link previews will keep hitting the old origin for a while, and keeping it alive means those visitors get a working site instead of a dead end. This also gives you a rollback that is one DNS record away.

Watch after the switch. Confirm the TLS certificate issued correctly on the new host, check for a 404 surge in your analytics or Search Console, and submit a sitemap crawl if anything about your URL structure changed (it should not have). Once traffic on the old project has been flat for a few days, delete it and remove any leftover DNS records.

The whole thing is one focused afternoon for a static site — provided you did the boring prep two days earlier.

How we evaluate hosting providers

Everything on HostingSpotter comes back to one question: what will you actually pay in month thirteen? We read the provider's own pricing page, then verify the renewal rate — the price after the first term — because that is where this industry makes its money and where comparison sites usually stop looking. We record introductory rates, renewal rates, and the percentage jump between them; we flag metered billing models that can surprise you (credit pools, usage floors that are not caps, bandwidth pooled across services); and we check what happens at the limits — build ceilings, transfer overages, idle timeouts — since those limits, not the marketing page, are what push people to migrate. Where I cannot verify a number, I say "at time of writing" and point you at the source rather than inventing precision. No ranking on this site is decided by who pays us; if a provider is bad value at renewal, that is what the review says.