Skip to content
cloudhostDocs
Products

Firewall

Every app and function has a firewall that runs on every edge server before your code does. The basic protections are always on; add rules of your own to deny, allow, log or rate limit requests. A change applies everywhere within seconds and restarts nothing.

Always-on protection#

These are on for every project, cost nothing and cannot be turned off:

ProtectionWhat it does
Flood protectionEach address may send a few hundred requests a second to one server; above that it gets 429 for a moment.
Malformed requestsRequests with oversized headers, bad paths or a broken protocol are refused before any rule runs.

The firewall's status is “normal”, or “mitigating” when one of these protections stopped a request in the last ten minutes.

Writing rules#

A rule has a name, conditions and an action. Conditions come in groups: the rule matches when every condition of at least one group holds (“and” within a group, “or” between groups).

FieldOperatorsValues
ipinaddresses or CIDR ranges (IPv4 and IPv6)
countryintwo-letter country codes, e.g. IR
methodinGET, POST, …
path, host, user_agenteq, starts, ends, contains, in, retext; re is a regular expression
header (name)the same, and existsthe value of the header you name
  • Any condition is inverted with neg: true (not on the command line), e.g. “header x-api-key does not exist”.
  • Text compares ignore case, except path. Regular expressions have no lookaround or backreferences; start with (?i) to ignore case.
  • The country comes from the request's address, looked up in a country database on the server itself; when it is not known, no country condition matches.
ActionMeaning
denyanswer 403; your code does not run
allowthe request goes through without the rules after it
logcounted and logged, then the next rule is checked
rate_limitmore than limit requests per window seconds for one key: 429 (or only logged, with then: log)

Rules run in order and the first deny, allow or exceeded rate limit decides. Change the order with position when creating, with cloudhost firewall move, or with PUT …/firewall/order. A disabled rule stays in the list and does not run.

cloudhost firewall add --project my-api --name "Block admin" --action deny \
  --if "path starts /admin" --if "ip not in 10.0.0.0/8"
cloudhost firewall add --project my-api --name "Bots without a key" --action deny \
  --if "user_agent re (?i)bot" --or --if "header:x-api-key not exists" --if "method in POST,PUT"
cloudhost firewall add --project my-api --name "Allow the office" --action allow --if "ip in 203.0.113.0/24" --position 0
cloudhost firewall rules --project my-api
cloudhost firewall move fwr_abc123def456 0 --project my-api
cloudhost firewall disable fwr_abc123def456 --project my-api

On the command line each --if is one condition: "<field>[:<header name>] [not] <op> [<value>]". Consecutive --if are one group and --or starts the next. For in the values are separated by commas; for the others the whole rest is one value.

Rate limits#

A rate_limit rule counts the requests that match its conditions per key: the address (ip, the default) or a header's value (header:<name>, e.g. your customer's API key). Windows are 10, 60, 300, 600 or 3600 seconds.

The count is shared between all the platform's servers and catches up within about a second; so the limit is for the whole project, not per server, and a little more may get through in the first second.

cloudhost firewall add --project my-api --name "Login limit" --action rate_limit \
  --if "path eq /login" --if "method in POST" --limit 10 --window 60 --key ip --then deny
cloudhost firewall edit fwr_abc123def456 --project my-api --limit 20

Test a request#

Before trusting a rule, see what it does with a request. Nothing is sent to the project and rate limits are not counted (one request is never over a limit).

CLI
cloudhost firewall check --project my-api --ip 203.0.113.7 --country DE --method POST --path /admin --header x-api-key=abc
# denied by rule fwr_abc123def456 "Block admin" → 403

Metrics, addresses and history#

The servers count, per minute, how many requests were allowed, denied, logged or rate limited and how often each rule matched; over the last 1 hour, 24 hours or 7 days. The addresses and countries with the most stopped requests are listed too. The counts are kept for 31 days.

Every rule change (create, update, enable and disable, delete, reorder) is recorded with who, when and the before and after in the firewall's history, and in the team's activity log.

CLI
cloudhost firewall --project my-api            # status, protections, rules, limits
cloudhost firewall metrics --project my-api --range 24h
cloudhost firewall audit --project my-api --limit 20

From an AI assistant#

The MCP server does the same: get_firewall, create_firewall_rule, update_firewall_rule, delete_firewall_rule, reorder_firewall_rules, check_firewall_request, firewall_metrics and firewall_audit. For example: “on my-api, limit POST requests to /login to ten a minute per address”.

Limits and price#

Limit (per app or function)HobbyProEnterprise
Custom rules340200
of them rate limits11050
Conditions per rule52050
Values per condition5010005000

Firewall checks are free and not metered. A request that is denied or rate limited never runs your code, so it is not counted or billed as a function request. GET /v1/pricing lists the rule limits (firewall_custom_rules, firewall_rate_limit_rules).

The limits are proposed and may change before launch.

Country data#

The country of an address comes from DB-IP (IP to Country Lite, November 2026), under the CC BY 4.0 license. IP geolocation by DB-IP.