Announcing Appwrite Firewall: traffic control for your project_
Appwrite Firewall adds project-level traffic rules to Appwrite Cloud. Deny, bypass, challenge, rate limit, or redirect requests to your API, Functions, and Sites, with an impact preview before every change.
Every application on the internet receives traffic it never asked for. Scrapers hit your API, bots probe your sign-up flow, and one misbehaving client can drown out everyone else. Until now, filtering that traffic meant putting a proxy or a third-party WAF in front of your backend and managing one more service.
Today, we are announcing Appwrite Firewall, project-level traffic control built into Appwrite Cloud. You define rules in the Console, and Appwrite applies them before requests reach your API, Functions, or Sites. No proxy to deploy, no DNS to change, and no extra service to keep alive.
How Firewall rules work
A Firewall rule combines four ideas:
- Resource scope: the traffic the rule considers. Choose the project API, one function, or one site.
- Conditions: filters on request attributes, such as IP address, hostname, path, method, headers, query parameters, user agent, country, or continent. Every condition on a rule must match.
- Action: what happens when the conditions match.
- Priority: the evaluation order. Lower numbers run first, and the first matching enabled rule decides the outcome.
Your rules live on the project's Firewall page, next to a live overview of what they do.
Five actions to shape your traffic
Each rule applies one action when it matches:
| Action | What the client receives |
|---|---|
| Deny | A 403 response before the request reaches your application |
| Bypass | Normal service, and later Firewall rules are skipped |
| Challenge | A verification step that filters out automated clients |
| Rate limit | Normal service under the quota, and a 429 response with a Retry-After header over it |
| Redirect | An HTTP redirect to the location you configure |
The actions compose. A bypass rule at priority 10 allowlists your office IP range, while a deny rule at priority 100 blocks everyone else on the same path. A rate limit with a per-IP or per-user quota protects your sign-in flow without touching normal users.
Create a rule in the Console
Rules take a minute to set up:
- Open Firewall in your project.
- Click Create rule.
- Name the rule, pick a scope, and build your conditions.
- Pick an action and set its options.
- Review the impact preview, then click Create rule.
The impact preview on the right estimates how many recent requests would have matched your conditions. It answers the question every firewall change raises: what will this rule actually hit? Tighten a path filter or narrow an IP range before the rule touches production traffic, not after.
Monitor every outcome
The Firewall page charts your traffic alongside every Firewall decision. The Passed series shows requests that got through, and dedicated series track denied, challenged, rate-limited, and redirected requests for the date range you select. Challenge rules also report how many challenges were solved and how fast.
One thing you never have to worry about: Firewall does not block the Appwrite Console. You keep full access to your project and your rules even while a broad deny rule is active, so an aggressive rule never locks you out of the tool you need to fix it.
Available today on Appwrite Cloud
Firewall is available for every project on Appwrite Cloud. Free organizations can create 2 rules per project, and Pro and Scale organizations can create 50. Disabled rules stay in your project and count toward the limit, but they are not evaluated.
The documentation covers the full model, plus step-by-step guides for the most common policies: country blocks, IP allowlists, rate limits on authentication traffic, bot challenges, and maintenance redirects.
