NETWORK & DOMAINS

Anti-DDoS and rate limiting

Absorb floods, throttle abusive clients and keep a public application reachable under load.

Two separate sets of controls, aimed at two different things. Per-application protection belongs to the project team and guards one application. The anti-DDoS console belongs to the platform administrator and guards the whole install. Mixing them up is the usual source of “I enabled it and nothing changed”.

	Per-application	Platform console
Guards	One application’s traffic.	The API and every application on the install.
Owned by	The project team (`protection:manage`).	Platform ADMIN with `config:manage`.
Enforced at	The reverse proxy, per application.	The kernel and the API edge.
Licensing	Included.	A Pro feature — the surface returns 403 without it.

The split is deliberate. The platform controls are global, so a tenant flipping one would affect every other tenant. The per-application controls are scoped to a single application, so its own members own them.

Protecting one application

On the application’s Protection tab:

Allow-list and block-list: CIDR ranges, rendered directly into the reverse-proxy configuration. Enforced at the proxy at essentially zero runtime cost — the request never reaches your container.
Rate limit: A request count over a window, and a ban duration for whoever exceeds it. Something like 300 requests per minute, banned for five.
Under Attack mode: Every visitor solves a CAPTCHA once, then carries a signed clearance cookie. For an active flood, not for everyday use.

Under Attack mode requires a configured CAPTCHA provider. Arming it without one means nobody passes the challenge — you have locked out your own users as thoroughly as any attacker could.

The tab also shows who is currently banned, with a button to lift any one ban. Counters that told you a ban existed without naming it, and gave you no way to lift it, are not an operational tool.

Add your own IP to the allow-list first — there is a one-click button for the address you are calling from. Rate-limiting yourself out of your own admin panel during an incident is a genuinely common way to lose an hour.

Every protection change is written to the audit trail. Blocking a range or arming Under Attack on a production application is a real-consequence action on a shared project, and it leaves a trace like any other sensitive write.

The platform console

Under Admin → Security, and gated three ways at once: the ADMIN role, the config:view / config:manage platform permission, and a Pro license carrying the anti-ddos feature.

Live telemetry: request rates, tracked addresses, active bans.
Global allow / block rules and manual bans, with a reason recorded against each.
A global Under Attack switch — local, plus Cloudflare’s own security level when a Cloudflare token is connected.
Kernel hardening applied to a remote agent server: SYN backlog, per-IP connection limits, SYN rate.
Ban propagation, so an address banned on one machine is banned across the fleet.

Windows, thresholds and ban durations are all configurable, each range-checked on write — a window of zero or a ban of a year are both refused rather than accepted into a config that then behaves strangely.

What this does not do

A volumetric attack that saturates your uplink is not solvable at the host. If the pipe is full, no rule running on the machine behind it can help — the packets already arrived. For that layer you need something in front: Cloudflare, your hosting provider’s scrubbing, or a dedicated service.

What these controls do handle well: application-layer floods, scrapers, credential-stuffing runs, and the single misbehaving client that is making your database slow for everybody else.