Tl;DR If you've been seeing the above over the last ~12 hours, you shouldn't anymore. Sorry about the mess, should be smooth sailing from now.

The Full story.

The pitch sounds simple. Put a small VPS in front of your self managed infra, run HAProxy on it, terminate the public internet there, hide your origin IP, get DDoS protection at the network edge. Skip Cloudflare. Skip AWS. Keep your TLS keys on your own hardware. Pay $16 a month instead of negotiating with someone's enterprise sales team for "free" service that scrapes your traffic to train models.

I spent the last 24 hours proving the pitch is simepl. I also spent much of that time learning that the path from "simple" to "actually working" runs down some dark and twisting roads.

The architecture, on paper, is one sentence: a small FreeBSD VPS in Vultr's Johannesburg region runs HAProxy in TCP-passthrough mode, dialing two WireGuard tunnels into my pfSense router over its dual WAN connections, forwarding all :443 traffic through to my origin's HAProxy where TLS terminates and the apps live. Vultr's network-edge DDoS protection absorbs floods. WireGuard hides the origin IPs. Active-active load balancing across both ISPs gives failover. DNS points at the VPS. Easy.

Everything in that sentence required learning what I didn't know I didn't know.

WireGuard cryptokey routing is not a network. I vaguely knew this. I forgot it when I configured two tunnel endpoints with the same destination IP and watched the kernel reject the second route as a duplicate. Two tunnels need two destinations. So I added a virtual IP alias on my routers's WireGuard interface, gave the second tunnel its own /32 to chase, and the routing table calmed down. The lesson generalised: every layer in this stack expects the underlying layer to look "normal," and "normal" is more specific than the docs suggest.

The PROXY protocol giveth and taketh away. Without it, my origin HAProxy sees every connection as coming from one of two WireGuard tunnel IPs — useless for rate-limiting, logging, or anything that cares about real users. With it, those tunnel-side bindings need accept-proxy set, and the public-facing bindings must NOT have it, and if you accidentally flip those bits the entire frontend serves browser-baffling TLS resets that look like a vendor outage but are actually a checkbox in pfSense's web UI. PROXY-v2 is plumbing that's invisible when it works and incomprehensible when it doesn't.

Suricata is not your friend by default. My intrusion detection system happily identified my own proxy's PROXY-v2 traffic as "Applayer Mismatch protocol both directions" and dumped the VPS's IP into a block table. Talk about shooting yourself in the ... router. WireGuard handshakes would succeed for a while, then mysteriously stop receiving bytes, then resume an hour later when the snort2c entry expired naturally. I spent considerable effort theorizing about stacked HAProxy worker processes, MTU mismatches, and connection pool exhaustion before realising my own perimeter defence was systematically betraying me. The fix was a one-line pass-list addition. The diagnostic path was a week.

Stick-tables are surprisingly literal. HAProxy's rate-limiting tracks source IPs, and when 500 internet users all arrive at your origin through one VPS tunnel, they look like one extremely busy client. Move tracking from tcp-request connection to tcp-request session so the PROXY-v2-unwrapped real IP is what gets counted. Now individual users get individual rate limits. But — and this is the part that took an evening of repeating self-inflicted denial, your LAN traffic is NAT'd through your own router's WAN IP before it gets to the VPS and back. So every LAN user, including you debugging at 3 AM, appears at the origin as one shared identity. Trip a rate limit once and you lock out yourself and everyone in the house. Add the WAN IPs to the trusted-source allowlist. Or, better, configure split DNS so LAN traffic doesn't pretend to be internet traffic in the first place.

429 is a 4xx. This sounds obvious until you write a rule that auto-bans clients who generate too many 4xx responses. Now a user who legitimately bursts past your rate limit gets 429s, those 429s count as errors, the error counter trips the auto-ban threshold, and the user is silently dropped for an hour for the crime of clicking around your site. The fix isn't subtle: remove the rule that treats your own rate-limit responses as evidence of malice. The bug was rule design, not edge case.

What this experience clarified is that the building blocks of "I want a load balancer in front of my servers" are all available, well-documented, mature, and individually correct. The hard part is the integration — the gaps between docs where one tool's reasonable default contradicts another tool's reasonable default and your traffic falls into the gap.

What you get for the effort is genuine: hidden origin IPs, real DDoS edge protection, dual-ISP failover with sub-10-second detection, IPv6 reachability for an IPv4-only origin, and your TLS keys still under your own roof. What you save: between $30 and $300 a month versus enterprise alternatives, depending on traffic. What you spend: an unreasonable number of hours learning HAProxy stick-table semantics in the middle of the night, and trying not to lock yourself out of your own infrastructure.

This experience also bears the reality of being a small business, I'm in UTC+2, when I go to sleep and something breaks, unless a kid wakes me up at 2am and I check the site, it won't be fixed till the morning. In general, systems are in place to be robust, and self healing, the problem is when the disaster system itself isn't setup correctly.

The trade is straight forward. The path through it is not. Big-tech CDNs hide all of this complexity for a reason — the reason is that the complexity exists and somebody has to absorb it. If you absorb it yourself, you own both the savings and the experience. The compromise everyone else makes for you costs them nothing and you everything.

Backstory

I shared a bit of my story, in this post the other day, about leaving a mainstream writing platform and starting my own. I'd only used the platform in question for a few months, growing disenchanted with it and building tuhat in March, and didn't have a large number of subscribers. I cross shared the article on the previous platform as a bit of a farewell.

This wasn't some slick marketing ploy; a few hours after sharing the article on Friday I got a ping from my log monitoring service about a spike in errors, as I hadn't checked if people could sign up for new accounts. Over the weekend, over a hundred people did. I didn't really think that people would take it as a call to action.

This isn't the front page of hackernews or producthunt, or even in the ballpark of viral in the world of the global behemoths and venture fueled crazy town. But it is a step in a positive direction, in finding people willing to try something different. Its my sapling, in what could be a global forest, of a truly distributed internet.

How & Why

I've started and run a handful of company in a box platforms for small businesses (one to five people small), and a food co-op network under the 8by3 umbrella, all with a geographic focus on South Africa, where I am based.

8by3 is a fully bootstrapped businesses, with no outside investment, no ridiculous cloud bill and very low overheads. I've been some twenty years in tech and got off the hype cycle, after seeing microservices and kubernetes everything gone very wrong. Now I run things small and simple. As I am already running all the infrastructure for those other endeavors, tuhat doesn't cost me much. And, doesn't have economic goals beyond scratching my own itch of wanting somewhere clean to write, and hopefully read.

Money

One day I'd like a way for authors to support themselves, I thought of something like librepay or one of the many buy me a coffee sites. Though am loathe for people to have to shell out to credit card companies. For now I am fine with having no profit motive, and for my other ventures to cover the costs.

New Features

Now that tuhat isn't just my personal blog, I figured I should add some niceties that people have come to expect. So you'll get dms, up voting, live video feeds, the ability to order a cab, lots and lots of articles promising five ways to hack the algorithm and win at tuhat'ing or some such.

Or, none of that. Just a quite place to write long form thoughts, privately let people know you loved their work and go about your day.

Actual new features, launched today.

Global Tags

Tags existed per user under eg. /u/sbr/t/social and they still do, but there is also a global /t/ and tags on the front page link to the global version eg. /t/social

The tag input field, takes a list of #random #words #with #hashes and it now suggests tags from the global index as you type, also shows the top 6 most common ones.

Better SEO

I always feel a bit dirty using the abbreviation SEO, but even the crusty anarchists want their articles on building a better world discoverable. There are some standard fields added to pages, improvements to the RSS feeds and the excerpt field and cover image which you can now set. These are pulled when sharing your links by crawlers.

Custom themes

Under site settings, you can pick one of a handful of predefined themes, which have different colours as well as styling etc. If none of the existing themes fit the bill, you can go to DasiyUI's generator and either artfully create your own or press random a few times and then tweak. Copy the generated css fields and paste them into the custom boxes. It allows you to create both a light and dark theme, there is no manual override, the page uses whatever your system is setup to do.

Whats next?

Probably not very much. I'm pretty time and focus poor with two small children and even more infant businesses on the go.

If something isn't working, either try again in 30s or use my contact form. I normally run a matrix server and can be found on there but its currently down for rather specific reasons that will make sense when its no longer down. I can also be pestered on irc.libera.chat #8by3.

Some idea's I've been toying with

A picture is one hundred words

I do a lot of photography, and sometimes might like to not write an actual 1000 words but share ten images, or 500 words and five images. A series of images is often called a photo essay and it feels true to the intent of long form content.

Supporting an author

I fully realize that people use substack or patreon as a way to make a living, and that's wonderful. I'd like to support that, I'd actually like to do it at a fraction of the cost that those platforms do, because I can. I don't have to pay off any investors and I run a very lean ship, I don't want to get rich quick, I want to support a sustainable lifestyle. I'd be curious if anyone has a novel approach to this problem and how it could be done without giving ~3% to credit card companies.

Something else

If you have an idea that is true to the principals of simplicity and privacy, feel free to suggest it. I might ignore it. Or if you've spotted something on tuhat that is plain wrong, either technically, legally or morally i.e from a design perspective. Let me know. I am a real person, reading and writing these words and can take real action to affect change on this platform.

Best,

sbr.

ps. For clarification, /o/tuhat is the official tuhat page, /o/8by3 is my company page, and /u/sbr my personal one.