--- name: azion-bind-a-firewall-to-a-workload description: >- Protect the domains of a workload with an existing firewall: name it in the workload's deployment from Azion Console or the Azion CLI. --- # Bind a firewall to a workload You can bind an existing [firewall](/en/documentation/platform/firewall/) to a [workload](/en/documentation/platform/workloads/) from Azion Console or the [Azion CLI](/en/documentation/devtools/cli/). To create a firewall, add its first rule, and bind it in one pass, refer to [Firewall quickstart](/en/documentation/platform/firewall/quickstart/). A firewall has no domain of its own. The workload carries the domains, and its deployment names the firewall that inspects their requests. The workload record itself holds no firewall field, so the binding lives on the deployment. For more information, refer to [How Workloads works](/en/documentation/platform/workloads/how-it-works/#the-deployment). An account that runs on API v3 with Domains binds a firewall in the settings of each domain instead. For more information, refer to [Domains](/en/documentation/platform/workloads/domains/). > **Tip** > > This page carries separate instructions for API v4 and API v3. To find out which apply to your account, refer to [Verify your account migration](/en/documentation/guides/application-security/access-and-compliance/verify-account-migration/). --- ## Prerequisites ### Console - A workload that serves an application. For more information, refer to [Workloads](/en/documentation/platform/workloads/). - A firewall with the rules the workload needs. To create a firewall, refer to [Firewall quickstart](/en/documentation/platform/firewall/quickstart/). To add rules to it, refer to [Create a firewall rule](/en/documentation/guides/application-security/firewall-and-waf/work-with-rules-engine/). - Access to Azion Console. For more information, refer to [Access Azion Console](/en/documentation/guides/platform/account-and-billing/how-to-access-azion-console/). ### CLI - A workload that serves an application. For more information, refer to [Workloads](/en/documentation/platform/workloads/). - A firewall with the rules the workload needs. To create a firewall, refer to [Firewall quickstart](/en/documentation/platform/firewall/quickstart/). To add rules to it, refer to [Create a firewall rule](/en/documentation/guides/application-security/firewall-and-waf/work-with-rules-engine/). - The [Azion CLI](/en/documentation/devtools/cli/), authorized with your account. This page matches Azion CLI 4.23.0. - The workload ID, the ID of the application the workload serves, and the firewall ID. The address of a firewall's page in Azion Console carries its ID after `/firewalls/edit/`. --- ## Bind the firewall to the workload A deployment carries exactly three settings: its application, its firewall, and its [custom page set](/en/documentation/platform/workloads/custom-pages/settings/). The application and the custom page set stay the ones the workload uses today, so the firewall is the only setting that changes. Until a deployment names the firewall, the firewall's rules see no request to the workload. A workload holds one deployment, so you change the deployment it has. A second deployment is refused with `The maximum number of deployments allowed per workload is 1.` For every field of the deployment, refer to [Workload settings](/en/documentation/platform/workloads/settings/#deployment). ### Console To bind the firewall in Azion Console: 1. **Open the Workloads page** Access [Azion Console](https://console.azion.com/) > **Workloads**. 2. **Open the workload** Select the workload whose domains the firewall protects. Its edit form opens. 3. **Select your firewall** In the **Deployment Settings** section, select your firewall in the **Firewall** field. In a workload with no firewall, the field reads *Select a Firewall*. **Application** and **Custom Page** keep the values the workload serves today. 4. **Save the workload** Select **Save**. After the save, the deployment of the workload names your firewall. ### CLI The deployment of a workload is written by `azion deploy`, from the [`deployments`](/en/documentation/devtools/cli/azion-config-js/#workload-deployments) entry of `azion.config.js`. To bind the firewall on an existing workload, follow the Console panel. --- ## Bind the firewall to a v3 domain An account that runs on API v3 has Domains in place of workloads, and binds the firewall on the domain itself rather than on a deployment. To find out which model your account runs on, refer to [Verify your account migration](/en/documentation/guides/application-security/access-and-compliance/verify-account-migration/). To bind a firewall to a domain in Azion Console: 1. **Open the domain** Access [Azion Console](https://console.azion.com/) > **Domains** > **the domain you want the firewall to protect**. 2. **Choose the firewall** In the **Settings** section, open the **Firewall** selector and choose the firewall. 3. **Save the domain** Select **Save**. The firewall then inspects the requests of that domain. The confirmation check reads the response of a request, whichever model served it. --- ## Confirm that the firewall applies its rules The check is the same for every interface. It needs a firewall rule whose answer you can recognize. This section uses a rule that denies every path that starts with `/deny-test`, such as the one in [Create a firewall rule](/en/documentation/guides/application-security/firewall-and-waf/work-with-rules-engine/). The firewall's rules can take several minutes to take effect on the workload after the binding, and no duration is guaranteed. Until then, requests reach your application as before. While the binding spreads, answers to the same request alternate between the old result and the new one. Repeat the request until it returns `403`. For more information, refer to [How Firewall works](/en/documentation/platform/firewall/how-it-works/#propagation). Send a request to the denied path. Replace `` with a domain the workload serves, such as its workload domain of the form `.map.azionedge.net`: ```bash curl -i https:///deny-test ``` The firewall refuses the request with `403`. This excerpt of the response leaves out its long `content-security-policy` header: ```text HTTP/2 403 server: nginx date: Thu, 01 Jan 2026 12:00:00 GMT content-type: text/html; charset=utf-8 x-content-type-options: nosniff x-azion-request-id: 0123456789abcdef0123456789abcdef x-azion-edge-location: alt-svc: h3=":443"; ma=86400 ``` The body is Azion's default error page, headed Forbidden, and it shows your IP address and the request ID. No response header identifies the firewall or the rule behind the refusal. Paths that no rule matches still reach your application. If `/deny-test` keeps reaching your application after the binding has had several minutes to propagate, refer to [Troubleshoot Firewall](/en/documentation/platform/firewall/troubleshooting/). --- ## Next steps - [Create a firewall rule](/en/documentation/guides/application-security/firewall-and-waf/work-with-rules-engine.md): Add a rule that denies one path, or a rule that requires a client certificate. - [WAF quickstart](/en/documentation/platform/firewall/waf/quickstart.md): Apply a WAF rule set to the firewall with a Set WAF behavior and see an injection-shaped request refused. - [Firewall best practices](/en/documentation/platform/firewall/best-practices.md#share-one-firewall-among-workloads-with-the-same-security-policy): Decide when workloads share one firewall, and what a change to it then reaches. - [Troubleshoot Firewall](/en/documentation/platform/firewall/troubleshooting.md): Find why a bound firewall does not act on the requests a workload receives.