How to Put Cloudflare in Front of Your Own Server

You do not have to choose between owning your server and having a real edge network. Put Cloudflare in front of your own VPS and you get a global CDN, DDoS absorption, and free TLS, while the box, the code, and the data stay entirely yours. This is the combination people miss when they assume self-hosting means exposing a raw IP to the whole internet. It does not. Here is how the layering works and why it keeps your ownership intact.

The mental model: your VPS is the origin, Cloudflare is a proxy in front of it, and users never touch your box directly. You get the benefits of a big network without renting your infrastructure from it.

Why put a CDN in front of a self-hosted box at all

Three reasons, and none of them require giving up control.

Speed. Cloudflare caches your static assets at edge locations close to users, so a visitor in another country is not waiting on a round trip to your single box. Your origin serves less and stays snappier.

Protection. A raw VPS with a public IP is a target. Point a botnet at it and the box falls over. Behind Cloudflare, your real IP is hidden and volumetric attacks get absorbed at the edge before they reach you. For a solo operator, that is protection you could not buy affordably any other way.

TLS without the chore. Cloudflare terminates HTTPS at the edge and you run encryption from the edge to your origin too. No manual certificate renewals to forget. This pairs naturally with owning the rest of the stack, which I cover in the deploy you actually control.

How to set it up without losing ownership

The setup is a handful of steps, and the key is keeping the origin fully yours.

Move your DNS to Cloudflare and point the record at your VPS with the proxy turned on (the orange cloud). Now traffic routes through their network before hitting you. Lock your origin firewall so the box only accepts web traffic from Cloudflare's address ranges and refuses everything else. That single step is what hides your real IP and stops attackers from going around the proxy.

Set encryption to full strict so the edge-to-origin hop is encrypted and verified. Run a certificate on your box, either an origin certificate from Cloudflare or a normal one. Turn on caching rules for your static paths and leave dynamic routes uncached.

That is it. Your app still runs on your box, your database still lives on your box, and you could pull the record and point DNS elsewhere in minutes. Nothing about this arrangement traps you, which is the test I apply to every vendor in what no vendor lock-in actually requires.

Is this cheating on self-hosting

No, and the distinction matters. Self-hosting is about owning your compute, your data, and your exit. Cloudflare in this setup owns none of those. It is a caching and filtering layer in front, not the place your app lives. Pull it out tomorrow and your server keeps serving; users just hit the origin directly and lose the edge cache.

Compare that to a PaaS, where your app, your database, and your deploy pipeline all live inside the vendor and leaving is a migration project. That is the difference I draw in PaaS versus a self-hosted VPS. A CDN in front is a swappable accessory. A platform underneath is a dependency. Keep the swappable things swappable and the load-bearing things yours.

What to keep on your box no matter what

Draw the line clearly. The edge can cache your assets and filter your traffic. It should never become the only place something lives.

Your database stays on your box or your own database server. Your uploads and object storage stay under your control. Your deploy pipeline stays yours. Your backups run independently and leave the fleet on their own path. If Cloudflare vanished overnight, your business should keep running with a DNS change, nothing more. That is the ownership boundary, and I hold the same line for servers that cannot be held hostage.

The layered stack I actually run

Across my fleet, every app sits behind this pattern: Cloudflare at the edge, a reverse proxy on the box handling routing and TLS, the app and shared database underneath. One pattern, reused for every product, which is exactly the kind of build-once platform I package into HostSSH. Adding a new site is adding a DNS record and a proxy entry, not standing up new infrastructure.

The lesson is not "avoid every big provider." It is "use them for what they are good at without letting them own you." A CDN in front of an owned box is the cleanest version of that: global reach on top, full control underneath, and the freedom to walk at any time.