---
layout: post
title: "Announcing Appwrite Firewall: traffic control for your project"
description: 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.
date: 2026-09-04
cover: /images/blog-local/announcing-appwrite-firewall/cover.avif
timeToRead: 6
author: arnab-chatterjee
category: product, announcement
featured: false
faqs:
  - question: "What is Appwrite Firewall?"
    answer: "Appwrite Firewall is project-level traffic control on Appwrite Cloud. You create rules that match requests by attributes such as IP address, path, method, headers, user agent, or location, and each rule applies an action before the traffic reaches your API, Functions, or Sites."
  - question: "Which actions can a Firewall rule apply?"
    answer: "A rule can deny a request with a 403 response, bypass later rules for trusted traffic, challenge a suspected bot, rate limit traffic over a quota with a 429 response, or redirect the client to another location. The first matching enabled rule decides the outcome."
  - question: "Can Firewall rules lock me out of the Appwrite Console?"
    answer: "No. Firewall does not block Console access. You can keep managing your project and its rules even when deny or rate limit rules are active for client and API key traffic."
  - question: "How do I know what a rule will match before I enable it?"
    answer: "The create wizard shows an impact preview. It estimates how many recent requests would have matched your conditions for the selected scope and date range, so you can tighten a rule before it affects production traffic."
  - question: "Which resources can a Firewall rule protect?"
    answer: "A rule scopes to the project API, to one function, or to one site. API rules protect requests to Appwrite services such as Auth, Databases, and Storage. Function and site rules protect the public traffic of the resource you select."
  - question: "Is Appwrite Firewall available on every plan?"
    answer: "Firewall is available on Appwrite Cloud. Free organizations can create 2 rules per project, and Pro and Scale organizations can create 50. Disabled rules count toward the limit but are not evaluated."
---

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](/docs/apis/rest), [Functions](/docs/products/functions), or [Sites](/docs/products/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.

![Firewall rules list in the Appwrite Console](/images/docs/firewall/dark/rules-list.avif)

# 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:

1. Open **Firewall** in your project.
2. Click **Create rule**.
3. Name the rule, pick a scope, and build your conditions.
4. Pick an action and set its options.
5. Review the impact preview, then click **Create rule**.

![Create firewall rule wizard with a deny rule](/images/docs/firewall/dark/create-rule.avif)

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.

![Firewall traffic overview with outcome metrics](/images/docs/firewall/dark/traffic-overview.avif)

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.

# Resources

- [Firewall overview](/docs/products/firewall)
- [Quick start](/docs/products/firewall/quick-start)
- [Actions](/docs/products/firewall/actions)
- [Conditions](/docs/products/firewall/conditions)
- [Block traffic by country](/docs/products/firewall/block-countries)
- [Allowlist trusted IP addresses](/docs/products/firewall/allowlist-ips)
- [Rate limit authentication traffic](/docs/products/firewall/rate-limit-auth)