---
title: "The bot swarms moved faster than my firewall rules"
canonical: https://dxdev.com/blog/2026-07-04_bot-swarms-moved-faster-than-my-firewall/
datePublished: 2026-07-04
---
The monitoring service calls my phone when the site goes down. Not emails. Calls. And for a stretch this spring it was calling nearly every day, at whatever hour the swarm decided to show up.

The pattern was always the same. Bot traffic would surge, the site would crawl or fall over, my phone would ring, and I'd be at a keyboard at 2am writing a firewall rule on the production server while paying customers couldn't load their pages. By the time my rule was live, the swarm had usually rotated: new addresses, new patterns, gone. I'd go back to bed knowing the rule I just shipped was already obsolete.

I want to be clear that this wasn't a naked server. I had many layers of bot protection built up over years, and they had handled everything before this. The latest generation of swarms went through them like they weren't there.

## getting faster at the wrong thing

My answer, for longer than I'd like to admit, was to get better at the scramble. Recognize patterns faster. Keep a library of rule templates. Tighten the existing layers. All of it amounted to the same thing: solving the problem on the same box that was under attack.

That has two failures baked in. The obvious one is speed. Deploying anything to a server that is currently drowning is slow, and slow is fatal against an attacker that rotates in minutes.

The subtle one is architectural. A firewall that lives on the serving box only acts after hostile traffic has already consumed a connection, a thread, and a slice of CPU on the exact machine I'm trying to protect. Even a perfect rule, deployed instantly, pays the toll first. The block fires, but the request already cost me the thing I was defending. I was spending my nights optimizing the speed of a response that was structurally too late, and the swarms kept proving it by rotating out of every pattern I caught within a few hours of catching it.

## moving the wall

The fix was a project I'd deferred for years because it was never urgent until it was: put Cloudflare in front of everything, and move enforcement there. Traffic decisions now happen upstream, on infrastructure that is not mine, not under attack, and reachable through an API.

The API part matters more than it sounds. Here is the whole move reduced to its shape. Before, mitigation was a login to the wounded box. After, it is one call to Cloudflare from a laptop nowhere near the fire:

```bash
# block a rotating swarm by fingerprint, from a healthy machine
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/firewall/rules" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -d '{"filter":{"expression":"cf.client.bot or http.user_agent contains \"<swarm-ua>\""},"action":"block"}'
```

That rule is live at every Cloudflare edge in well under a minute, and not one of those seconds is spent on my server. During an incident now I describe the pattern to my AI agent, it writes the expression, pushes it, and confirms the block took effect, all from a machine that is perfectly healthy. The 2am version of me, hand-editing rules on a wounded server, is now a sentence typed into a terminal. Sometimes typed from my phone.

Migrating an old platform with thousands of customer domains onto Cloudflare was its own saga, and the hardest part is still in progress. That story is its own post. But the enforcement move alone changed what an attack feels like. It became something I handle in a few minutes and forget by morning.

## the box that's on fire

There is one question worth sitting with. If a flood hit right now, would stopping it require touching the machine being flooded? For years my answer was yes, and that is the whole bug: the box you must log into is the box that's on fire.

Cloudflare didn't make my rules smarter. It moved them off the machine I was trying to save. The swarms still come, near-daily some weeks, but the migration that made this survivable is only half done. Thousands of legacy domains still need to move behind the edge before every one is covered, so I keep a list of which are safe and which aren't, and I check it every time the phone rings.
