Three countries. One campus. One obsession.
We met in a graduate program at a university in the northeastern United States — the kind of place where you pull 18-hour days in a lab and argue about systems design over bad coffee at 2am. One of us had crossed the Atlantic from England, where he'd spent years working in carrier-grade network infrastructure before deciding academia could teach him something. Another came from Germany, with a background in low-level systems programming and an almost unhealthy obsession with squeezing performance out of commodity hardware. The third was American, raised in the Midwest, and had spent his teenage years helping his uncle run a small regional ISP in rural Ohio.
What brought us together wasn't a class or a research project. It was a conversation in a university hallway about a paper on high-speed packet processing — and a shared feeling that the state of network security for anyone who wasn't a Fortune 500 company was, frankly, a mess.
The ISP that was drowning.
After graduation, we went separate ways. The Englishman moved back to London to work at a network equipment firm. The German stayed in Europe, taking a role at a software house in Berlin. The American came home to the Midwest to build infrastructure for a mid-sized hosting company. We stayed in touch — the kind of intermittent contact you maintain when you respect someone's work and know paths will cross again.
Then came the phone call. The American's uncle — the one who had been running that small ISP in Ohio since the late nineties — was in trouble. His network had been under sustained DDoS attack for three weeks. Not the massive terabit floods you read about in the news. Something more calculated: repeated volumetric bursts, just enough to saturate his uplink, knock his customers offline for 20 to 40 minutes, then stop. Then repeat. Day after day.
The existing solutions weren't designed for him. They were designed for banks, CDNs, and enterprises with security teams and six-figure budgets. For a small ISP with a handful of employees and a community of customers depending on them — there was nothing. Either you paid the scrubbing center, or you absorbed the attack, or you shut down.
We had a call that weekend. All three of us. And somewhere between frustration and stubbornness, we made a decision: we know how to build this. Not a product. Not a startup. Just a solution — something that actually works, that runs on hardware you can buy at any server reseller, that doesn't require a BGP session with a scrubbing center or a contract with a vendor who's never heard of your city.
Nights, weekends, and a lot of arguing.
We started building in early 2020, entirely in our spare time, across three time zones. The German handled the core engine — the low-level packet processing layer that needed to be both fast enough to matter and stable enough to trust in production. The Englishman focused on the cluster architecture: how multiple nodes would share state, discover each other, and fail gracefully without dropping a single legitimate connection. The American built the management layer — the part that had to be simple enough for a one-man ISP to operate without a PhD.
We made dozens of decisions that commercial vendors don't make because their incentives run the other way. We chose to run on commodity Intel hardware because that's what small operators already have, or can buy for a few hundred dollars. We designed it to be completely transparent — no routing changes, no BGP sessions, no new IP addresses — because small ISPs don't have network architects on staff to redesign their topology. We built it to run on the operator's own hardware, not ours, because we weren't interested in building a managed service. We wanted people to own their protection.
A live attack. Three nodes. Zero downtime.
The first production deployment was the Ohio ISP. We flew in — one from London, one from Berlin, one already there — spent two days setting up three physical nodes between the edge router and the core, and handed over a USB drive with the installation ISO and a single piece of paper with the Web UI address and login credentials.
The attack came back four days later. Same pattern as before: multi-vector bursts designed to saturate the uplink. This time, the three nodes distributed the traffic across themselves via the LACP bond, inspected every packet in real time, and dropped the malicious flood before it reached anything behind them. The operator's customers didn't lose a single connection. The attack ran for over an hour. The ISP didn't notice it had happened until they checked the dashboard the next morning.
That was the moment we knew it wasn't just an engineering experiment. It was something real.
No marketing. Just word of mouth.
We never ran ads. We never gave talks at conferences or posted press releases. The Ohio operator told another ISP in Indiana. That one told a regional carrier in the south of England. Someone in Germany mentioned it to a colleague running a small hosting operation in Hamburg. Slowly, without us doing anything to accelerate it, IronDome started appearing in more networks.
Each new deployment taught us something. A regional ISP in the UK had a different LACP topology than what we'd seen in the US — we adapted. A hosting operator in Germany needed per-service rate limiting to protect individual customers without impacting others — we built it. A cluster deployment in the American Southeast surfaced a subtle state synchronization edge case under extreme flood conditions — we fixed it at 3am on a Tuesday, the three of us on a call, the same way we always have.
We kept our names off it. Not out of secrecy, but because we always believed that if the tool works, it speaks for itself. The people who use it know how to reach us. That's enough.
Still the same three engineers. Still the same goal.
IronDome is now running in small and mid-sized ISPs across the United States, the United Kingdom, and continental Europe. Every deployment still runs on hardware the operator owns. Every license is priced so that the ISP in rural Ohio — or rural Bavaria, or rural Yorkshire — can actually afford it. We've never taken outside investment. We've never had a sales team.
The three of us are still the ones who answer the support emails, review every pull request, and get on calls when something needs to be understood before it can be fixed. We've added an automated installation ISO, a multi-client management platform, and cluster modes that can scale from two nodes to as many as a network needs. The core commitment hasn't changed: this should work for the people who need it most, not just the ones who can afford enterprise contracts.
We still argue about systems design. The coffee is better now.