Fighting a Bot Swarm at the Server Never Worked. Moving the Defense to the Edge Did.

My phone rang in the middle of the night, and I already knew what I was going to see when I opened my laptop. The site would be moving like it was stuck in mud. People who paid to use it would be waiting for pages that would not load. Somewhere, a large group of automated visitors would be hammering at the door.

The phone calls came nearly every day for a stretch that spring. They did not arrive as polite emails I could read over coffee. They were calls, at whatever hour the traffic showed up. Sometimes I was at a keyboard at 2am, trying to fix a live problem while the thing I needed to fix was already struggling to stay awake.

The visitors were bots, which just means computer programs visiting a site instead of people. Some bots are useful. Search engines use them to find pages. The ones showing up here were not useful. They arrived in swarms, changed their behavior quickly, and made it hard for normal customers to get through.

I had protections already. This was not a case of leaving the front door wide open and acting surprised when a crowd came in. Over years, I had added layers meant to catch bad traffic. They had handled the earlier problems. This new wave slipped through them anyway.

For too long, I tried to get faster at the scramble. I kept examples of rules I could reuse. I got better at spotting a pattern. I tightened the protections already on the site. Each time the phone rang, I logged into the production server, the computer doing the real work for customers, and wrote another rule there.

That effort did not solve the real problem. By the time I had a rule ready, the swarm had often changed its addresses or its calling card. I would block what I had just seen, then watch the crowd arrive wearing a different coat a few hours later. I lost sleep. Customers lost time and patience because their pages could not load. And every late-night fix was built on the same bad idea: I was trying to reinforce a door while the crowd was already pushing it off its hinges.

The term for one kind of rule I was making is a firewall. It is simply a gatekeeper that decides who gets through. The trouble was where that gatekeeper lived. Mine was sitting inside the same machine the crowd was overwhelming.

That meant every unwanted visitor still got close enough to take something before the gatekeeper could say no. It used a connection and a little bit of the computer’s attention. One visitor was not the problem. A crowd of them was. Even a perfect rule could not give back the little pieces that had already been spent.

The change was not a smarter rule. It was moving the gate.

I put a service called Cloudflare in front of the site. Think of it as an outside checkpoint, far away from the shop itself. When traffic arrives, the checkpoint can decide whether to let it continue before it reaches the computer doing the customer work. If an unwanted crowd shows up, the crowded machine no longer has to meet every person at the door first.

That new location changed the feel of an incident. Before, stopping a swarm meant logging into the wounded machine. After, it meant making a change from a healthy laptop. The new instruction could reach the outside checkpoints in less than a minute, without spending any of that minute asking the overloaded site to do more work.

I can now describe the pattern I am seeing to an AI agent. It can turn that description into a proposed instruction, send it to the outside checkpoint, and confirm that the block took effect. That is useful speed, especially in the middle of the night. But the important decision is still mine. I have to be sure I am looking at a harmful pattern, not an ordinary customer or a verified search crawler. Fast help is only helpful when the person using it knows what should not be shut out.

This is not finished. Thousands of older customer addresses still need to move behind that outside checkpoint. Until they do, not every site has the same protection. When the phone rings, I still check a list to see which side of the move that site is on.

What changed was where the gate stands, not how clever the rule is. Before, stopping a swarm meant logging into the production server the crowd was overwhelming to write one more rule. Now a block reaches the Cloudflare checkpoints in less than a minute from a healthy laptop, and it is usually a few minutes of work I can forget by morning.

dxdev LESSON · paste into your AI coding agent
LESSON: When an attack overwhelms a machine, move the defense to a checkpoint in front of it instead of writing faster rules on the machine under load
SOURCE: dxdev.com/blog/2026-07-04_night-i-stopped-fighting-at-the-door
WHAT HAPPENED: For a stretch one spring, swarms of bots slowed a live customer site nearly every day, with phone calls at all hours. Layers of protection built over years missed the new wave. Each time, the operator logged into the production server and wrote another rule there, but by the time a rule was ready the swarm had changed its addresses or its calling card. The firewall lived on the same machine the crowd was overwhelming, so every unwanted visitor still used a connection and some of the computer's attention before being refused. The change was to put Cloudflare in front of the site, so a new block reaches the outside checkpoints in less than a minute from a healthy laptop without asking the overloaded site to do more work. An AI agent can turn a described pattern into a proposed rule, send it, and confirm it took effect, while a person decides whether the pattern is harmful and not an ordinary customer or a verified search crawler. Thousands of older customer addresses were not yet moved behind the checkpoint.
THE RULE: A defense should not live on the machine it is protecting while that machine is under load. Put the first checkpoint outside it, and keep a person deciding what counts as harmful before an automated block is sent.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any incident response step that requires logging into the overloaded production machine to write or apply a block.
  2. Any bot or abuse protection that runs only on the origin server, so unwanted requests still consume its connections and CPU before being refused.
  3. Any automated block rule generated from a described pattern with no human review of whether it could block real visitors or verified search crawlers.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.