Cloudflare Hosting: What It Actually Hosts, and What It Only Fronts

Cloudflare hosting covers two very different products: Pages, Workers and R2, which really do run your code and store your files, and the classic proxy, which only sits in front of a server that lives somewhere else.

People search this phrase expecting one answer and get two. If your site is static files or a small edge function, Cloudflare can be the whole host. If your site is a Rails app, a Django project, a WordPress install or anything that wants a long-running process and a database, Cloudflare is the shield in front and you still need a real server behind it. Mixing those two up is how people end up with a fast CDN pointed at nothing.

Table of contents

• The two meanings of Cloudflare hosting
• What Cloudflare genuinely hosts
• What Cloudflare only fronts
• When you still need an origin server, and where it should live
• Setting up the hybrid: Cloudflare in front of a real origin
• Where the origin should actually run
• How this fits the rest of the stack
• FAQ

The two meanings of Cloudflare hosting

Cloudflare started as a reverse proxy. You change your nameservers, traffic to your domain flows through Cloudflare’s network first, and Cloudflare caches what it can, filters what looks hostile, and forwards the rest to your origin. In that role Cloudflare hosts nothing. Your files, your process and your database live on a server you rent elsewhere, and turning the proxy off makes the site keep working, just slower and more exposed.

The second meaning is newer. Cloudflare now runs a developer platform where the code itself executes on their network: Pages for static sites and their build pipeline, Workers for JavaScript and WebAssembly functions, R2 for S3-compatible object storage, plus data products like D1 and KV. In that role there is no origin at all. The domain points at Cloudflare and Cloudflare answers.

The quick test is simple. Open the DNS tab and look at the record type and target. A proxied A record pointing at an IP address you rented from someone else means Cloudflare is fronting. A Pages project or a Worker route attached to the domain means Cloudflare is hosting. Plenty of sites run both at once: static marketing pages on Pages, an API on a separate origin behind the proxy.

Knowing which one you are actually using matters because the failure modes differ. A fronting setup fails when the origin is down, and the error page says so (a 52x code). A hosted setup fails when you hit a platform limit, such as a request duration, a bundle size or a runtime API that does not exist at the edge.

What Cloudflare genuinely hosts

Pages is the closest thing to traditional website hosting. You connect a Git repository, set a build command and an output directory, and every push produces a deploy with a preview URL per branch. It is a good fit for Astro, Hugo, Eleventy, Vite and most framework output that ends as HTML, CSS and JavaScript. Server-rendered frameworks can run through Pages Functions, which are Workers underneath.

Workers run code at the edge on the V8 isolate model rather than in a container. That gives very fast cold starts and global distribution, and it also means you are not running Node the way you do on a server. There is no long-lived process, no local disk you can count on, and CPU time per request is capped. Many Node packages work, but anything that expects native binaries, a filesystem or a raw TCP listener does not.

R2 stores objects behind an S3-compatible API, and the pitch that matters is the absence of egress fees, which makes it a sensible home for images, downloads and backups that get read a lot. KV, D1 and Durable Objects cover key-value, relational and coordinated state; our Cloudflare databases breakdown covers when each fits.

For the official picture, Cloudflare’s own application hosting overview lists the products; read it with the limits pages open beside it, because the marketing page will not mention a request that runs too long.

What Cloudflare only fronts

Everything with a persistent server process. WordPress, Laravel, Django, Rails, a Node API with an in-memory queue, a game server, a Mastodon instance, an n8n install. These need a runtime that stays up, a filesystem or a database socket, and sometimes background workers. Cloudflare’s proxy will happily cache their static assets and absorb junk traffic, but it will not run them.

This is also the honest answer to a question that keeps coming up in search: can Cloudflare replace my VPS? For static and edge-shaped workloads, yes. For the rest, no. We went through the details in Cloudflare VPS, and the summary is that the edge runtime is a different programming model, not a cheaper server.

Fronting still earns its place. A proxy hides your origin IP, terminates TLS at the edge, caches cacheable responses, and gives you a firewall you did not have to build. The trade-off is one more layer to debug. When something breaks you now have to ask whether the fault is the browser, the edge, the cache rule, or the origin, and the first three are not yours.

• Cacheable static assets (images, CSS, JS): the proxy helps a lot.
• HTML from a dynamic app: cache only if you are sure about cache keys and cookies.
• API responses with auth headers: bypass the cache and let the proxy just pass through.
• WebSockets and long-lived streams: supported on the proxy, subject to plan and timeout limits.

When you still need an origin server, and where it should live

The rule of thumb: if the code needs a process that stays running, a database connection pool, a local file, or a runtime that is not JavaScript at the edge, you need an origin. That includes most backends built in Python, Ruby, Java, .NET or PHP, and any Node service that uses native modules.

Where the origin lives is a latency and reliability decision. Cloudflare will shave the first hop for cached content, but every cache miss still travels to the origin, so put it near your users and near your database. If your database is in one region and your origin is in another, the proxy cannot hide that round trip. Keep the app and the database in the same region and private network where possible.

The second decision is how the origin is protected. Fronting is only a shield if the origin refuses direct connections. Otherwise anyone who finds the raw IP, via old DNS records, mail headers or a certificate transparency log, can bypass the proxy completely. Lock the origin down to Cloudflare’s published IP ranges, or use an authenticated tunnel, and rotate the IP if it was ever public.

A minimal check that the origin only answers through the proxy looks like this:

# should fail or time out once the origin is locked down
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" http://203.0.113.10/ -H "Host: example.com"

# should succeed through the proxy
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/

If the first command returns 200, your shield has a hole in it, and the free tier of anything will not fix that.

Setting up the hybrid: Cloudflare in front of a real origin

The most common production shape is a hybrid. Static assets or the marketing site on Pages, the application on an origin, the whole domain proxied. The order of operations matters because certificate issuance and proxying interact.

1. Deploy the origin first and confirm it answers on its own hostname over HTTPS.
2. Add the custom domain to the origin and let it issue its certificate while DNS is still unproxied (grey cloud).
3. Point the record at the origin, then switch on the proxy (orange cloud).
4. Set the SSL mode to Full (strict) so the edge validates the origin certificate instead of trusting anything.
5. Add cache rules only for paths you have checked, and bypass the cache for authenticated routes.

Skipping step 2 is a classic: proxying before the origin has a valid certificate can break the HTTP validation the origin needs, and the fix takes an hour of staring at a redirect loop. Flexible mode hides that problem by talking plain HTTP to the origin, which is why it should be treated as a last resort and not a default. Our Cloudflare Flexible explainer covers the redirect-loop trap in detail.

Record types are worth a glance too. Cloudflare flattens apex CNAMEs, so pointing the bare domain at a hostname works, which many origins rely on. The second-level detail is in our Cloudflare DNS servers post.

Where the origin should actually run

Once you accept that you need an origin, the question becomes what kind. A raw VPS means you own the operating system, patching, firewall, backups and process supervision. It is a great learning box and a poor way to run a business site at three in the morning. A managed platform takes the runtime, build, TLS and rollback off your plate, and you keep the proxy in front for what it is good at.

What you want from the origin behind Cloudflare is boring on purpose: a stable hostname, a certificate that renews itself, logs you can read when the proxy returns a 52x, and a rollback for the deploy that broke it. A database in the same private network as the app helps more than any cache rule.

That combination is what a managed web service gives you: connect a GitHub repo, get a build log, a live route, a custom domain, and runtime logs, and put the proxy in front once the direct route works. Bad deploys roll back to the previous version instead of becoming an incident. If your project is a static site alone, the custom domain and certificate docs cover the DNS side, and the same records work whether or not you add a proxy afterwards.

How this fits the rest of the stack

Cloudflare is an excellent front door and, for static and edge-shaped work, a decent house. For everything with a long-running process, keep the proxy and put the app on a real origin. If you are weighing what that origin would cost as a web service plus a managed database, the RunxBuild hosting calculator puts the line items in one place before you commit. When you are ready to try the direct route, open the RunxBuild dashboard, deploy from GitHub, confirm it works on its own hostname, and only then turn the proxy on. Related background: Databases on RunxBuild for the data layer that sits behind the origin.

Useful related references:

• Cloudflare VPS: What the Edge Can and Cannot Replace
• What Cloudflare Is Actually Used For
• Cloudflare Free Plan: What You Get and Where It Stops
• Custom domains and certificates on RunxBuild

FAQ

Is Cloudflare a web host?

Partly. Cloudflare Pages, Workers and R2 genuinely host static sites, edge functions and files, so a static site can live entirely on Cloudflare. The classic Cloudflare setup, however, is a proxy in front of a server hosted elsewhere, and in that mode Cloudflare hosts nothing and cannot run a PHP, Python or Ruby application.

Can I host a WordPress site on Cloudflare?

Not directly. WordPress needs PHP and a MySQL database running continuously, and neither runs on Pages or Workers. The normal pattern is to host WordPress on a server or a managed WordPress plan and put Cloudflare in front for caching, TLS and firewall rules, with cache bypass rules for the admin area.

Is Cloudflare hosting free?

There are free tiers: Pages and Workers each have free allowances with request, build and size limits, and the proxy has a free plan. Free is fine for static sites, prototypes and small projects. Check the current limits pages before depending on them for anything with real traffic, because the caps are the whole story.

Do I still need an origin server behind Cloudflare?

Yes, unless your whole app fits Pages and Workers. Anything that needs a persistent process, a database connection pool, a filesystem or a non-JavaScript runtime needs an origin. Cloudflare then caches and protects it, while the origin does the actual work and answers cache misses.

What SSL mode should I use with an origin?

Full (strict). It encrypts both hops and validates the origin certificate, so a misconfigured or expired origin certificate gets noticed instead of hidden. Flexible mode sends plain HTTP to the origin and commonly causes redirect loops, so treat it as a temporary workaround at most.