1. Home
  2. Guides
  3. Next-Gen WAF
  4. Setup and configuration

About deploying the Next-Gen WAF

To deploy the Next-Gen WAF, you need to integrate the Next-Gen WAF product into your request flow by:

  1. Choosing a deployment method. A deployment method outlines how the integration is set up. All of our deployment methods rely on the same architecture components but have different host locations (e.g., Fastly’s Edge Cloud platform and customer's local environment) and parties who maintain the active deployments.

    HINT: You can use more than one deployment method. For example, you may want to use the Edge WAF deployment method to protect your web applications that are behind the Fastly CDN and the On-Prem WAF deployment method for your other web applications.

  2. Setting up your deployment by following the appropriate guide for your selected deployment method.

  3. (Optional) Using attack tooling to verify that the Next-Gen WAF is monitoring your web application and identifying malicious and anomalous requests.

Before you begin

The Next-Gen WAF can be purchased for an account by contacting sales@fastly.com. Once purchased, our staff will create a Next-Gen WAF corp (account) and at least one site (workspace) for your use when you log in.

Choosing a deployment method

The key differences between our deployment methods are where the deployment is located and who maintains the deployment.

Deployment methodLocationFastly managedCustomer managed
Edge WAFFastly’s Edge Cloud platform via our global network of POPs✔
On-Prem WAFCustomer's local environment✔
PaaSSupported vendor platform✔
A10 NetworksA10 Networks✔
Cloud WAFFastly’s cloud infrastructure✔

About Edge WAF deployment

The Edge WAF deployment method hosts the Next-Gen WAF on Fastly’s Edge Cloud platform via our global network of POPs and integrates with Fastly’s caching layer, Varnish. Since security processing happens at the edge, the Next-Gen WAF can inspect all traffic before it enters your origin infrastructure and block attacks close to where they originated. The sequence diagram below shows the Edge WAF request flow, which we explain in greater detail in our How the Edge WAF works guide. To use this option, you must have a Fastly delivery account.

Sequence diagram showing the Edge WAF request flow between the web client, Fastly service, Edge WAF, and origin. The flow begins with the client request to the Fastly service, which searches the cache for the requested objects. If the objects are found (cache hit path), the service returns the cached response directly to the client. If the objects aren't found (cache miss path), the service forwards the request to the Edge WAF for inspection. If the request is malicious, the Edge WAF blocks it and returns a block response via the Fastly service to the client. If the request is legitimate, the Edge WAF allows the request to continue to the origin. For allowed requests, the origin generates a response, which gets sent to the Edge WAF and Fastly service for final processing before getting delivered to the client.

About On-Prem WAF deployment

The On-Prem WAF (formerly known as Core WAF) deployment method hosts the Next-Gen WAF directly on your local environment, which means you are responsible for managing the deployment. By deploying at your origin core, you are able to inspect traffic from any path that it took to your origin infrastructure. This means that you can inspect east-west traffic that hops from one internal server to another within the client origin.

This method includes both module-agent and reverse proxy deployment options.

Deployment optionComponents you must installConsiderations
Module-agent
  • Next-Gen WAF module
  • Next-Gen WAF agent
  • This option has a fail-open design, meaning the module verifies agent availability and allows all traffic when the agent is down.
  • The module hooks into the request mechanism on your environment, so you don’t need to change how you're handling TLS termination.
  • The module can exist as a plugin to your web server or be deployed at the application layer.
  • The only Next-Gen WAF module variation that supports WebSocket inspection is the NGINX dynamic module.
Reverse proxyNext-Gen WAF agent
  • This option has a fail-close design, meaning all traffic is blocked when the agent is down.
  • This option does not require you to make modifications to your web server or code, which is helpful for old and fragile environments.
  • The agent performs the role of both the deployment entity and agent components.
  • This option supports WebSocket inspection.
  1. Module-agent with traffic management layer
  2. Module-agent with application layer
  3. Reverse proxy

The sequence diagram below shows the request flow for a module-agent deployment where the module exists as a plugin to your web server.

Sequence diagram showing the module-agent request flow, where the module exists as a plugin to your web server. The request flow is between the web client, traffic management layer and Next-Gen WAF module, Next-Gen WAF agent, and backend application. The flow begins with the client request to the traffic management layer and module, which forward the request to the agent for inspection. The agent then sends a decision back. If the decision is block, the traffic management layer and module return a block response to the client. If the decision is allow, the traffic management layer and module forward the request to the backend application. The backend application generates a response and sends it to the traffic management layer and module. The traffic management layer and module deliver the response to the client and forward the response to the agent.

About Kubernetes deployment patterns

The On-Prem WAF deployment method supports multiple deployment patterns in Kubernetes. For the Next-Gen WAF to work in Kubernetes, you will need to customize configurations. Our documentation provides several examples of Kubernetes deployments that use the Docker sidecar container pattern.

About Platform as a Service (PaaS) deployment

You can deploy the Next-Gen WAF product within a supported vendor platform by embedding the Next-Gen WAF agent within the selected platform. The sequence diagram below shows the request flow for a PaaS deployment.

Sequence diagram showing the PaaS request flow between the web client, Next-Gen WAF agent, and PaaS. The flow begins with the client request to the agent, which inspects the request. If the request is malicious, the agent returns a block response to the client. If the request is legitimate, the agent allows the request to continue to the PaaS. The PaaS generates a response, which gets sent to agent and then the client.

NOTE:

Fastly services interoperate with non-Fastly services only when you configure them that way. We do not provide direct support for non-Fastly services. Software or services that enable integration with non-Fastly services (such as plug-ins, extensions, and add-ons) are available under their own terms. Read Fastly's Terms of Service for more information.

About embedded service deployment with A10 Networks

IMPORTANT: This deployment option requires an A10 feature license for activation.

The Next-Gen WAF can be deployed as an embedded service with A10 Networks on select A10 Thunder and vThunder application delivery controller (ADC) form factors. A10 Networks provides support for A10 deployments. To learn more about the A10 ADC Next-Gen WAF deployment option, contact your Fastly account manager or email our Sales team.

NOTE:

Fastly services interoperate with non-Fastly services only when you configure them that way. We do not provide direct support for non-Fastly services. Software or services that enable integration with non-Fastly services (such as plug-ins, extensions, and add-ons) are available under their own terms. Read Fastly's Terms of Service for more information.

About Cloud WAF deployment

IMPORTANT:

Only Next-Gen WAF customers with access to the Next-Gen WAF control panel can use this solution.

The Cloud WAF deployment method hosts the Next-Gen WAF on Fastly’s cloud infrastructure and consists of several Cloud WAF instances. Each instance is made up of a load balancer along with at least three Next-Gen WAF agents, each operating in reverse proxy mode and installed on separate redundant machines. The sequence diagram below shows the request flow for a Cloud WAF deployment.

Sequence diagram showing the Cloud WAF request flow between the web client, Next-Gen WAF agent, and origin. The flow begins with the client request to the agent, which inspects the request. If the request is malicious, the agent returns a block response to the client. If the request is legitimate, the agent allows the request to continue to origin. The origin generates a response, which gets sent to agent and then the client.

To use the Cloud WAF deployment method, you must upload a TLS certificate, add an origin server using the Next-Gen WAF control panel, and update your DNS records to point to the appropriate servers.

What's next

After setting up your deployment, the Next-Gen WAF will immediately start monitoring traffic to your website, detecting requests with malicious and anomalous payloads, and populating request data to the Next-Gen WAF control panel. To ensure legitimate traffic isn’t blocked, the Next-Gen WAF allows all requests initially.

To start blocking malicious traffic, set the Agent mode (Protection mode) setting to Blocking. You can also create rules to adjust the protection of your website and make sure the Next-Gen WAF blocks and allows the correct traffic.

Related content

Fastly
© Fastly 2025