Pulseguard
Under Attack?DDoS Protection
Absorbed before it reaches you.
Point a verified domain at the PulseGuard edge and every request is scored before your origin sees it. Real visitors pass straight through; automated abuse gets a challenge, a rate limit, or a block. Every one of those decisions takes about a millisecond.
- Decision time per request
- ~1ms
- Verdicts the edge can return
- 5
- Signed challenge tokens
- Ed25519
- Per verified domain
- Opt-in
Every request gets a verdict.
Traffic on the left, the decisions it produced on the right, each with the reason code and risk score behind it. Nothing about the verdict is a black box to you, and none of it is visible to the visitor.
A gate that thinks before it blocks
Blocking is easy. Blocking abuse without blocking customers is the part that takes a real decision engine.
Risk scored per request
IP reputation, user-agent automation signals, request headers, rate history, and whether the visitor already holds clearance combine into one score, evaluated synchronously, before anything is forwarded.
Challenge, don't refuse
A suspicious visitor gets a proof-of-work or interactive challenge rather than a door slammed in their face. A real person gets through; a script that can't execute the challenge doesn't.
Cleared once, then left alone
Passing a challenge issues a signed clearance cookie, so a visitor isn't re-challenged on every page. The binding tolerates ordinary mobile IP churn instead of breaking mid-session.
Good bots stay welcome
Major search-engine crawlers are verified by reverse DNS before being allowed through, so protecting the site doesn't quietly cost you your search ranking.
Your rules come first
Ordered firewall rules match on path, method, IP, header, country, or ASN and decide the outcome directly. That is how you say 'never challenge /webhooks' or 'always block /wp-admin' without touching the risk engine.
Every decision is readable
Each verdict carries a reason code and a score, visible in your dashboard with seven days of analytics. When something legitimate gets challenged, you can see exactly why.
What you can tune
Protection mode and sensitivity are the two dials most teams touch. Everything below them is there when a specific path or a specific client needs different treatment.
Protection mode
Off, log-only, or enforcing. Log-only runs the full decision engine and records what it would have done. It is the safe way to turn this on for the first time.
Sensitivity
How high a risk score has to climb before a challenge is issued, so a login page and a marketing page don't have to share one threshold.
Rate limiting
Per-IP burst thresholds backed by Redis, with temporary blocks for clients that keep hammering after being limited.
Trusted IP ranges
CIDR ranges that bypass challenges entirely. Your office, your CI runners, a partner's integration.
Path exclusions
Paths that must never be challenged, for webhook receivers and API callers that can't solve one.
Challenge type
A silent JavaScript proof-of-work for most traffic, or an interactive puzzle when a visitor should be asked to do something explicit.
What happens to a request
One pass through the edge, in this order, for every request that arrives.
- 1
The hostname is resolved to your config
The Host header maps to the domain, its firewall configuration, and its ordered rules, cached briefly so the lookup doesn't cost a database round-trip per request.
- 2
Context is gathered
Client IP, user-agent, existing clearance cookie, rate-limit history, temporary block state, IP reputation, and verified-bot status. This is the only I/O in the path.
- 3
A pure function decides
The verdict (allow, log, challenge, rate-limit, temp-block, or block) comes from synchronous logic with no network calls, which is what keeps the added latency around a millisecond.
- 4
Allowed traffic is forwarded
The request goes to your origin and the response streams back. A cleared visitor's experience is a normal page load with no interstitial.
- 5
Challenged traffic proves itself
A self-contained challenge page is served, and solving it issues a signed clearance cookie. Requests that were mid-flight with an unsafe method are replayed afterwards rather than lost.
DDoS Protection, answered.
No, and it would be dishonest to say otherwise. This is application-layer protection: it stops floods of HTTP requests, credential stuffing, scraping, and bot abuse before they reach your origin. A network-layer volumetric attack large enough to saturate the link needs Anycast routing, distributed capacity, and upstream scrubbing from your hosting or transit provider. Run this alongside that, not instead of it.
Turn it on in log-only mode first.
Watch a week of real traffic get scored before a single visitor is challenged.