'Mount Snowdon through Clearing Clouds' by Alfred William Hunt, 1857. | Getty Museum (edited by the Author)
Choosing Friction and Clear Skies: I’m No Longer Using Cloudflare
Last night, I was in the omg.lol IRC chatroom as I often am. I got talking about my folk.zone project, how I got my own IRC server up-and-running and was now working on getting an instance of BookWyrm spun up.
Pablo Murad, a fellow web tinkerer, asked me about how I was running the project, and how I dealt with CGNATs blocking port forwarding for home servers. I explained I was lucky enough to have a fixed public IPv4 address, and that I was using Cloudflare's Zero Trust Tunnelling system to bypass the whole ordeal anyway.
Then, Adam, the creator of omg.lol chimed in. And this led to a heart-to-heart conversation that made me realize I need to slow down with everything—for the only reason I started folk.zone was because I have been a passionate user of omg.lol for the past year.
He explained how none of omg.lol uses Cloudflare's infrastructure, despite the fact the alternatives are much more difficult and expensive, but it was worth it because of how unethical and antithetical Cloudflare is to the IndieWeb ethos.
Unethical?
Now, I already actively dislike Cloudflare, I've written about how they are an infrastructure monopoly, and how much unilateral power their CEO has, and that I'm extremely lucky to be able to use Deflect.ca as my CDN and DDoS-protection on Brennan.day.
I only began using Cloudflare when I started running full-stack web infrastructure from my home hardware and creating projects meant for use by other people, such as Fanfiction.lol. To me, the security and accessible nature of Cloudflare made it seem worth using, despite my problems with it.
But Adam disagreed, and he opened my eyes to how I was being complicit in using a web service that is not at all compassionate or human-centered. CEO Matthew Prince has hid behind the supposedly-noble concept of neutrality to enable infrastructure for malicious, hateful websites such as the Daily Stormer, 8chan, and KiwiFarms. Sure, he eventually capitulated and stopped providing service to these entities, but only after grave, real-world harm had already been done.
In practice—in our messy reality—there is no neutrality. The act of doing nothing is taking a side, and the Silicon Valley libertarian types such as Prince will side with what profits their company over what the compassionate, human response ought to be.
Furthermore, as I mentioned in my previous article on Cloudflare, they're a privacy nightmare, acting as a man-in-the-middle for HTTPS traffic, meaning they are able to see all unencrypted traffic passing through their network. Decrypting HTTPS, inspecting packets, and re-encrypting on the other side. This is what it means to be a reverse proxy.
Many people online are apathetic to the fact they are using free services in exchange for giving up their information, their attention, their data. But I certainly should not enable this. I should not help normalize this theft and surveillance capitalism.
I should not be complicit in using easy-to-use free web infrastructure for my projects. Yes, it is an effective tool for the security of my site, and the security of my personal home hardware. But so what? My ethos and values have always been to strongly resist convenience culture and instead take the slow, difficult, deliberate path forward.
All of this is to say that folk.zone will take more time and effort to get online the way I want to get it online. Through the proper, ethical channels. If I'm going to create a project for the IndieWeb, I certainly don't want to be using a tool that is so blatantly corporate and callous towards people.
Luckily, this isn't actually a big deal. I just started the project a few days ago and nobody is using (much less dependent on) its services.
Really, I wanted to create folk.zone to prove to people that self-hosting and contributing to the IndieWeb commons isn't a difficult task—and even without Cloudflare, there are parts of it that are still surprisingly low-effort.
You do not need expensive hardware to self-host. Here are all the containers running on my 8GB of RAM and a 2012 CPU.
You Don't Need to Reinvent the Wheel
The magic of modern self-hosting is that you don't have to build anything from scratch. Every service that was running on folk.zone: the Mastodon instance, the Forgejo forge, BookWyrm, WriteFreely—all exist as prebuilt Docker container images, maintained by the upstream project developers and freely available to pull and run. Docker is, at its core, a way to package software and all of its dependencies into a portable, isolated environment so that it runs consistently regardless of what else is on the same machine.
Docker Compose is what ties those containers together. It lets you define an entire multi-service stack in a single YAML file: here is my Mastodon instance, here is the PostgreSQL database it depends on, here is the Redis cache, here is how they talk to each other. The command docker compose up -d boots the whole thing. No dependency conflicts, no version collisions between services that need different versions of the same library.
The piece that routes the internet to the right door is Caddy. Caddy is a web server and reverse proxy, and the reason I use it over nginx or Apache is because it handles HTTPS automatically. Point it at a domain and it negotiates and renews a certificate from Let's Encrypt without you ever touching OpenSSL. You write a simple Caddyfile that says "requests for books.folk.zone should go to the BookWyrm container on port 8080," and that's it. With the community-built caddy-docker-proxy, you can go one step further and define those routing rules directly inside your Compose file as container labels, keeping all configuration in one place.
On four modest machines, I can run fifteen-plus federated services on consumer hardware, with valid HTTPS, without any of them fighting over ports or conflicting with each other. The complexity becomes so much more manageable.
The Many Moving Parts Replaced
What exactly does ripping out Cloudflare Tunnel mean in practical terms? Cloudflare bundles many different moving parts of web infrastructure.
The first thing it handles is connectivity. The tunnel works by having a small daemon called cloudflared open an outbound-only, encrypted connection to Cloudflare's edge. Your services never need an open inbound port, all traffic arrives through there. Without it, you instead open ports on your router and forward them to your server. Since I have a fixed public IPv4 address, this is straightforward, but it does mean my home IP is now visible to anyone who resolves folk.zone.
The second thing Cloudflare handles is DDoS protection and bot mitigation—absorbing attacks at their global edge before they reach your hardware. This is where Anubis comes in as a wonderful alternative. Built by the Canadian open-source shop Techaro, it sits in front of your services and requires any connecting client to pass a JavaScript-based proof-of-work challenge before getting through. Trivial for a real browser, expensive at scale for automated scrapers and AI crawlers. It's become a standard for the small web: GNOME, FFmpeg, FreeBSD, and UNESCO all deploy it now. Anubis is a meaningful deterrent against the kind of traffic that's currently killing small community servers. Paired with fail2ban, which watches server logs and bans IP addresses exhibiting abusive patterns, you have reasonable protection. Not enterprise-grade, but ethical and within your control.
The third piece Cloudflare handles is SSL/TLS termination, their edge decrypts HTTPS traffic before it reaches your origin. As I've already mentioned, Caddy actually does the negotiating and renewing certificates directly from Let's Encrypt, so nothing extra needed there.
The fourth is CDN caching. Cloudflare caches static assets at edge nodes globally, speeding up load times for far-flung visitors. I don't have a direct replacement for this, but at folk.zone's current scale I don't need one. The project is early, the user base is small, and most of the services are dynamic anyway.
And perhaps most promising of all, Pangolin is a fully self-hosted, open-source equivalent to Cloudflare Tunnel. It's built on WireGuard and licensed AGPL-3, giving you the same outbound-only tunnel model but with full control over the relay server. You do need to run it on a cheap VPS, and then your home hardware connects outward through it. The project cutely names its components after the burrowing animals. Pangolins, newts, gerbils.
Principled.
I want to add here that Adam was insistent that his choice to not use Cloudflare for omg.lol was a personal one, and was adamant (Adamant? heh) that he understood that for a project like mine, it made sense from a cost-perspective and didn't criticize me whatsoever for my original choice of using Cloudflare. All of the above came from my own introspection after our discussion. And this isn't the first time I reorganized my entire codebase after having a conversation with someone far more thoughtful and intelligent than me.
Adam shared omg.lol's principles with me, and I really think what he is doing is wonderful and should be an example for anybody interested in being a web community leader.
I still have the hardware, I still have the email SMTP, I still have the domain names, I still have the drive. It will take a little longer and more elbow grease to get everything up and running, but so what? That sounds like fun, to me.
Comments
To comment, please sign in with your website:
How it works: Your website needs to support IndieAuth. GitHub profiles work out of the box. You can also use IndieAuth.com to authenticate via GitLab, Codeberg, email, or PGP. Setup instructions.
Signed in as: