Skip to main content
Agentgateway is configured through YAML or JSON files (the two formats are fully equivalent). Configuration is split into three forms: static config for global process settings, local config for full proxy configuration with hot-reload, and XDS config for remote control plane management.

File format

Configuration files use the following top-level structure:
Adding the # yaml-language-server comment at the top of your config file enables schema validation and autocompletion in editors that support the YAML Language Server.
JSON is fully equivalent to YAML:

Static configuration

The config block contains settings that are read once at startup. These control global behaviors that apply to the entire process.
Static configuration changes require a process restart. Use local config or XDS for anything that needs to change at runtime.

Static config reference

Local configuration

The dynamic part of the configuration — binds, listeners, routes, backends, and policies — lives outside the config block. When you run Agentgateway with a config file, it watches the file for changes and hot-reloads the configuration without restarting.

File watch reloads

1

Initial load

At startup, Agentgateway reads the config file and translates it into the Internal Representation (IR). The proxy begins handling traffic.
2

File change detected

When the file is modified (saved), the file watcher detects the change and re-reads the file.
3

Validation and translation

The new configuration is validated and translated into a new IR. If validation fails, the old configuration stays in place and an error is logged.
4

Atomic swap

The new IR atomically replaces the old one. In-flight requests complete against the old configuration. New requests use the new configuration.
You can also point config.localXdsPath to a separate file that contains only the dynamic configuration (binds, listeners, routes, backends). This keeps static and dynamic config cleanly separated.

Configuration hierarchy

The dynamic configuration follows a strict hierarchy: bindslistenersroutesbackends, with policies attachable at the route level.

Binds

A Bind defines a TCP port to listen on.

Listeners

A Listener defines how connections on a port are handled. Multiple listeners on the same port are distinguished by hostname.

Routes

A Route matches incoming requests and applies policies before forwarding to backends.
Match types:

Backends

A Backend defines an upstream target. The type is inferred from the fields you provide.

Policies

Policies are attached at the route level and control authentication, authorization, rate limiting, observability, and traffic shaping.

Real-world examples

Architecture

Understand how static config, local config, and XDS map to the proxy’s Internal Representation

CEL expressions

Write authorization rules and transformation expressions using CEL