Own Your Servers, Rent the Edge

Most small teams end up with the same setup: email at one provider, DNS at another, the website on a builder, monitoring on a SaaS dashboard. Each service is cheap and easy on its own. Together they leave your data, your configuration and your uptime with companies that can change prices, terms or features whenever they like.

The opposite extreme, doing everything yourself including DDoS protection and a global CDN, isn't realistic either. A single VPS can't absorb an attack or serve a static page from 300 cities.

The split that works: keep the state on servers you own, and rent the stateless edge. Your mail, your zones, your sites and your data live on your machine. Cloudflare sits in front of what benefits from a global network and costs nothing or very little to put there.

Why your own server

Your data stays yours. Mailboxes, DNS zones, access logs and databases sit on a disk you control. You know where they are, who can read them and how long they're kept. For a European business, knowing where personal data lives is also a GDPR requirement.

No lock-in, if you choose plain formats. An nginx config, a Maildir and a BIND zone file can be read on any Linux box. Moving to another provider means copying files, not exporting from a proprietary dashboard and hoping the import works.

Predictable cost. A 4 GB VPS costs the same whether you host one site or twenty, and whether you have five mailboxes or fifty. There's no per-seat pricing and no surprise "you've exceeded your plan".

You understand your stack. When something breaks, you can read the logs. The skills you build running your own server carry over to every job that touches Linux.

What it costs you

Self-hosting has a cost, and it should be named:

• Maintenance: security updates, certificate renewals and disk space are now your job.
• Backups: nobody else is keeping a copy. If the disk dies and you have no offsite backup, the data is gone.
• One machine is one point of failure: a single VPS is only as available as its provider and your configuration.
• Exposure: every open port is reachable by the whole internet, attacks included.
• Mail deliverability: you're responsible for PTR, SPF, DKIM, DMARC and the reputation of your IP.

Most of these can be managed with good tools and a few habits. Some of them are exactly where the edge helps.

Where Cloudflare fits

Cloudflare's free and low-cost services cover the things a single server does badly. Each one solves a specific problem.

A sensible way to use them:

• Landing pages and docs on Pages. Static HTML doesn't need your server. Moving it off frees resources and removes one thing to patch.
• Busy or exposed sites behind the proxy. Cloudflare terminates TLS, caches static assets and absorbs floods before they reach you.
• Admin panels behind Tunnel and Access. The panel listens on 127.0.0.1, cloudflared publishes it, and Access asks for a login first. The port is never open to the internet.
• Backups to R2. Encrypt them first (rclone with a crypt remote works well) so the provider only stores ciphertext.

What must stay direct

Not everything can or should go through Cloudflare.

• Mail. The proxy and tunnel carry HTTP, not SMTP. Your MX record has to point straight at your server on port 25, with a PTR record that matches the hostname.
• SSH. Keep it direct, key-only and limited to your own addresses. If the tunnel or your Cloudflare account has a problem, SSH is how you get back in.
• An exit plan. Renting the edge can become lock-in too. Keep your DNS records documented, and make sure the server can serve traffic directly if you ever turn the proxy off.

For DNS you can go one step further: run your own authoritative server as a hidden primary and let a secondary service answer the world. You edit the zone on your machine, the secondaries pull it with AXFR after each NOTIFY, and your server is never queried directly.

The detail everyone gets wrong: the real client IP

Put a proxy in front of nginx and every request appears to come from Cloudflare. Your access logs fill up with Cloudflare addresses, rate limits hit the edge instead of the client, and fail2ban starts banning Cloudflare, which takes your site offline for everyone.

nginx can restore the real address with the realip module, trusting the header only from Cloudflare's own ranges (published at cloudflare.com/ips-v4 and cloudflare.com/ips-v6):

# behind the Cloudflare proxy
set_real_ip_from 173.245.48.0/20;   # ...one line per published range
real_ip_header   CF-Connecting-IP;

# behind cloudflared on the same machine
set_real_ip_from 127.0.0.1;
set_real_ip_from ::1;
real_ip_header   CF-Connecting-IP;

Two mistakes to avoid:

• Trusting the header from everyone. Anyone could send a fake CF-Connecting-IP and write whatever address they like into your logs.
• Leaving the origin open. If ports 80 and 443 accept connections from anywhere, attackers can skip Cloudflare and hit the server directly. Behind the proxy, allow those ports only from Cloudflare's ranges. Behind the tunnel, don't open them at all.

The ranges change from time to time, so refresh them on a schedule rather than pasting them once.

A reference layout

The NetForge lab puts this together on one 4 GB VPS: static, PHP, reverse-proxied and load-balanced sites reached directly, through the proxy and through a tunnel; mail arriving directly on port 25; DNS served as a hidden primary with public secondaries; admin panels reachable only through the tunnel, and SSH kept direct as the emergency way in.

Checklist

• Data on your server, in formats you can read without the tool that wrote them
• Encrypted offsite backups, tested by actually restoring them
• Static sites on Pages, not on the VPS
• Proxied sites: realip from Cloudflare ranges only, origin ports limited to those ranges
• Tunneled sites: listen on 127.0.0.1, no inbound ports
• Admin panels behind Access, never public
• Mail and SSH direct, SSH key-only
• An exit plan if you ever leave Cloudflare