Skip to content

Firewall · flood shield · bot controls

Attacks stop at the edge

Every request to your app first meets an OWASP web application firewall, an attack mode for HTTP floods, controls for AI crawlers and per-visitor limits. Built into the EU platform your app already runs on, configured per service, included.

Thousands of home connections, a few requests each

GET / · GET / · GET / …

  1. Connection limits

    Open connections are capped per address before TLS.

    Connection limits: A few connections each

  2. AI crawlers

    Training crawlers, or every AI crawler, refused if you choose.

    AI crawlers: Not a crawler

  3. Shield

    Attack mode: browsers prove themselves once, everything else is held to 10 req/s.

    Shield: Attack mode: browser check

  4. Rate and in-flight limits

    100 requests a second per visitor, bursts of 200, and a cap on requests in flight.

    Rate and in-flight limits: Never reached

  5. Web application firewall

    The OWASP Core Rule Set reads the URL, query string and headers.

    Web application firewall: Never reached

  6. Your app

    Only what got this far.

    Your app: Never reached
The layers every request to your service meets at the edge, in order. Pick the traffic to see where it stops. Example addresses and references.
Four layers, one edge

Firewall, flood shield, crawler controls and limits

Configured per service from the dashboard, the CLI, the API or MCP. Included with every web service, on every team.

Web application firewall

The OWASP Core Rule Set, in front of every route

SQL injection, path traversal, remote code execution, PHP and WordPress exploits and scanner probes are recognised at the edge, before your code runs.

  • Per service: off, detect or block, with paranoia level 1 or 2
  • Detect first: see what would have been blocked, with the rule that fired, before you block anything
  • A blocked visitor sees a reference id you can look up in WAF events, kept for 7 days
  • A false positive is one click: disable that rule for the service. WordPress exclusions are applied for you
Firewall docs

HostStack Shield

An attack mode for HTTP floods

Modern floods come from botnets of home connections, each too slow to trip a per-address limit. Attack mode asks browsers to prove themselves instead.

  • Browsers pass an invisible proof-of-work check once every 30 minutes, nothing to click
  • APIs and webhooks are never challenged; they are held to 10 requests a second per address
  • Googlebot, Bingbot, Applebot and YandexBot pass, proven by reverse DNS, not by user agent
  • Turn it on by hand at any time. Automatic attack mode is rolling out in stages
Shield docs

AI crawler controls

Decide which AI crawlers read your site

One setting per service, enforced at the edge with no extra hop for anyone else.

  • allow, block_training, or block, which refuses AI search crawlers too
  • Fetchers acting for one person in a chat are never blocked, like a browser
  • /robots.txt stays readable to every crawler
  • The crawler list ships with the platform, so there are no user-agent rules for you to write
AI crawler docs

Edge limits

Limits on every service, and a CDN that counts

Every hostname is rate-limited per visitor from the first deploy, with caps on concurrent requests and connections.

  • 100 requests a second per visitor by default, bursts of twice that, adjustable from 10 to 5,000
  • Caps on requests in flight per visitor and per hostname, and on open connections per address
  • Behind Cloudflare or Bunny, each real visitor is counted, not the CDN’s address
  • Optional origin lock: refuse every connection that did not come through your CDN
Limits and CDN docs
Where the edge stops

What it protects, and what it does not

The edge defends your app against attacks that arrive as HTTP requests. Here is what sits outside that, and what to do about it.

  • Volumetric floods are filtered upstream

    Floods aimed at the network itself (SYN, UDP and amplification attacks) are filtered by Hetzner, the EU network the edge runs on. HostStack does not run its own anycast scrubbing network.

  • A check is a cost, not a wall

    Most flood tools never run JavaScript, so the browser check stops them cold. A determined scraper can still solve it slowly, which is why the per-address limits stay on underneath.

Expecting something very large?

Put Cloudflare or Bunny in front, and lock the door behind it

For the largest volumetric attacks, a global CDN absorbs traffic before it reaches any single network. HostStack is built to sit behind one:

  1. 1Tell the service which CDN it is behind. The edge's limits then count each real visitor, not the CDN's few addresses.
  2. 2Turn on the origin lock. Any connection that skips the CDN and comes straight to our servers is refused.
Set up a CDN in front
Driven from anywhere

Built for the way you actually tune a firewall

The dashboard, the CLI, the TypeScript SDK and the MCP server all change the same settings. They apply on the next deploy.

  • Detect first, then block

    Run the firewall in detect mode for a few days, read what it would have stopped, disable the rules your own traffic trips, and only then switch to block.

  • Webhooks stay out of it

    Exempt up to 20 paths from Shield, so a payment provider’s retries never meet a limit chosen for a flood.

  • Told when it engages

    Each service’s Shield tab records when attack mode turned on, its peak rate and how many addresses took part. Your alert channels can subscribe to it.

  • Readable by your agent

    WAF events and Shield state are in the API, the SDK and the MCP server, so the agent in your dev box can tell an attack from a bug.

From the terminal
# Detect mode: nothing is blocked, everything is logged
hoststack services update svc_abc --waf-mode detect

# A week later: drop the rule your own traffic trips, then block
hoststack services update svc_abc --waf-disabled-rules 932200
hoststack services update svc_abc --waf-mode block

# Expecting trouble? Attack mode on, webhooks exempt
hoststack services update svc_abc --shield-mode on \
  --shield-exempt /api/webhooks/*

# Keep AI training crawlers out
hoststack services update svc_abc --ai-crawlers block_training
Before you ask

Edge protection questions

DDoS, false positives, attack mode, crawlers and cost.

Does HostStack protect against DDoS attacks?

Against the kind most sites actually get, yes. HTTP floods, the commonest attack on web apps today, are handled at our edge: per-visitor rate limits on every service, and Shield, an attack mode that sends browsers through an invisible proof-of-work check while holding other requests to 10 a second per address. Volumetric attacks on the network itself are filtered upstream by Hetzner. We do not run our own anycast scrubbing network, so if you expect very large volumetric attacks, put Cloudflare or Bunny CDN in front of your domain; HostStack is built to sit behind either.

Will the firewall block my own users?

It can, which is why it starts in detect mode. In detect mode nothing is blocked: every request the rules would have blocked is listed under WAF events with the rule that fired, for 7 days. Disable any rule your own traffic trips, then switch to block. Request bodies are inspected and reported but never blocked, so uploads and form posts are not held up, and WordPress sites get the Core Rule Set’s WordPress exclusions automatically.

Is attack mode automatic?

Automatic attack mode, which turns on when a domain gets several times its usual traffic from many different networks and turns off after 15 calm minutes, is rolling out to services in stages. You can turn attack mode on by hand for any service today, and off again when you are done.

Will attack mode break my API, webhooks or SEO?

No. Only browsers opening a page are shown the check; API calls, webhooks and fetch requests are never challenged, just held to 10 requests a second per address while attack mode is on. You can exempt up to 20 paths entirely. Googlebot, Bingbot, Applebot and YandexBot pass without a check, verified by a reverse DNS lookup confirmed by a forward one, and the check page is never cached or indexed.

Can I block AI crawlers from training on my site?

Yes. Set AI crawlers to block_training and crawlers that collect training data, such as GPTBot, ClaudeBot and CCBot, get a 403 at the edge. Set it to block and AI search crawlers are refused too, which also takes your site out of those engines’ answers. Fetchers that load one page because a person asked for it in a chat are never blocked, and /robots.txt stays readable.

Does it cost extra?

No. The firewall, Shield, AI crawler controls and edge limits are included with every web service, on every team, at no extra charge.

Deploy behind a firewall from day one

Every service you deploy gets the edge limits straight away. Turn on the firewall in detect mode, and keep attack mode a switch away.