Agentgateway в standalone-режиме: запуск, модель конфигурации и продовые настройки

Когда LLM в команде пользуются многие, ключи провайдеров расползаются по .env-файлам, расход токенов никто не считает, а MCP-серверы каждый подключает сам и с любыми командами. Agentgateway закрывает эти три дыры одной точкой входа: пользователи ходят к моделям и MCP через шлюз, администратор выдаёт ключи, ставит лимиты и видит расход.

Проект написан на Rust в Solo.io, входит в Linux Foundation, исходники открыты на GitHub. Первый тег v0.0.2 вышел в марте 2025 года, актуальный — v1.6.0.

Что умеет шлюз

проксирует запросы к LLM-провайдерам;
проксирует MCP и A2A (agent-to-agent);
управляет трафиком: считает потраченные токены и применяет лимиты, добавляет и удаляет заголовки, проверяет содержимое запросов;
маршрутизирует инференс.

Развернуть можно двумя способами: standalone-контейнером или в Kubernetes. Для homelab и небольшой команды хватает первого.

Из альтернатив того же класса есть lunar.dev и MCPJungle. При выборе стоит проверить две вещи, на которых они спотыкаются: работает ли продукт без доступа в интернет и что зашито в docker-образ. В одном из образов нашлись переменные окружения с учётными данными и внешним хостом, на который отправляются логи. Для шлюза, через который идут промпты и ключи, это достаточная причина отказаться.

Запуск в Docker

Пример для версии 1.5.0. Забираем образ и создаём каталог, в котором будут лежать config.yaml и файл базы SQLite:

docker pull cr.agentgateway.dev/agentgateway:v1.5.0
mkdir agw-config

Запускаем контейнер:

docker run -d \
  --name agentgateway \
  --user "$(id -u):$(id -g)" \
  -v "$PWD/agw-config:/config" \
  -p 127.0.0.1:4000:4000 \
  cr.agentgateway.dev/agentgateway:v1.5.0

Порт привязан к 127.0.0.1 намеренно: авторизация в UI ещё не настроена, и публиковать его на всех интерфейсах рано. В логах после старта видно, откуда загружен конфиг и какие порты заняты:

info state_manager loaded config from File("/config/config.yaml")
info state_manager Watching config file: /config/config.yaml
info app serving UI at http://localhost:4000/ui
info management::hyper_helpers listener established address=127.0.0.1:15000 component="admin"
info management::hyper_helpers listener established address=[::]:15020 component="stats"
info proxy::gateway started bind bind="bind/4000"

Три порта: 4000 для трафика и UI, 15000 для admin-интерфейса (слушает только loopback), 15020 для статистики. Строка Watching config file означает, что шлюз следит за изменениями config.yaml.

Дальше открываем http://localhost:4000/ui, на стартовом экране включаем блоки LLM и MCP и жмём Continue.

Пять сущностей конфигурации

Gateway — точка входа: именованный порт и эндпоинты, через которые приходит трафик. Здесь же выбирается протокол (HTTP, HTTPS, TCP, TLS) и подключаются сертификаты.

Listener — слушатель внутри gateway. У каждого gateway есть минимум один. Несколько слушателей нужны, когда у шлюза несколько хостнеймов и для каждого свой TLS-сертификат.

Route обрабатывает и перенаправляет входящий трафик. Маршруты объявляются на верхнем уровне конфига и привязываются к gateway по имени, поэтому один маршрут можно использовать в нескольких gateway.

Backend — куда уходит запрос: IP-адрес, хостнейм, LLM-провайдер или MCP-сервер.

Policy — правила управления трафиком, мониторинга и безопасности. Набор доступных политик и момент их срабатывания зависят от объекта, к которому они привязаны:

Объект	Доступные политики	Когда срабатывает
Gateway или listener	JWT, внешняя авторизация, внешняя обработка, трансформация, Basic Authentication, API-ключи	До выбора маршрута
Route	Все	После выбора маршрута, до выбора бэкенда
Backend	Backend TLS, backend-авторизация, backend HTTP и TCP, AI/LLM, MCP-авторизация, внешняя авторизация, изменение заголовков запроса	После выбора бэкенда

Практическое следствие: проверку API-ключа ставят на gateway, чтобы неавторизованный запрос отсекался до маршрутизации, а настройки конкретной модели или MCP-сервера — на backend.

Провайдеры, модели и MCP

Провайдер добавляется в разделе Providers кнопкой Add provider — список готовых вариантов там длинный. После этого в разделе Models заводится модель и привязывается к созданному провайдеру.

Для MCP-серверов поддерживаются три транспорта: Streamable HTTP, SSE (считается устаревшим) и Command Line.

Настройки, без которых шлюз не стоит выпускать в сеть

OIDC для админки

UI нужен только администраторам: пользователям хватает эндпоинта подключения и MCP. Если есть GitLab или другой OIDC-провайдер, вход настраивается в Settings → OIDC, а список конкретных пользователей с доступом — в Settings → Authorization. До этого шага UI должен оставаться на loopback.

Read-only конфиг

Любое изменение в UI переписывает config.yaml (его текущее содержимое видно в Tools → Raw configuration). Если конфиг лежит в git и раскатывается автоматически, правки через интерфейс создают дрейф. Решение — снять права на запись с файла: шлюз продолжит его читать, а изменить не сможет.

HTTPS

Gateway поддерживает протокол HTTPS и подключение сертификатов. Через шлюз идут API-ключи и содержимое промптов, так что HTTP допустим только на loopback.

sensitiveHeaders

Заголовки с секретами попадают в логи и трассировки, если их явно не перечислить:

config:
  sensitiveHeaders:
    - x-api-key
    - cookie
    - x-tenant-secret

Три детали поведения:

поле читается только при старте, после правки шлюз нужно перезапустить;
маскировка выполняется дважды — при поступлении запроса и после трансформаций и backend-выражений CEL, поэтому заголовок, созданный трансформацией, тоже будет скрыт;
скрывается только вывод трассировки и отладки. На бэкенд уходит реальное значение, и в CEL-выражениях оно по-прежнему читается, так что политики и пользовательские поля логов, завязанные на этот заголовок, продолжают работать.

API-ключи с лимитами

Пользователь получает ключ у администратора шлюза. На каждый ключ задаётся лимит потребления токенов и список разрешённых моделей.

Цены на токены

Для каждой модели задаётся стоимость в USD за четыре типа токенов: input, output, cache read, cache write. Значения правятся в конфиге или переопределяются в UI. Без них лимиты на ключах работают некорректно: шлюзу нечем пересчитать токены в деньги. С заполненными ценами в UI появляются графики потребления.

Порядок внедрения

Поднять контейнер на loopback, завести провайдера и одну модель, проверить запрос через шлюз.
Прописать sensitiveHeaders и перезапустить — до того, как в логах накопятся чужие ключи.
Настроить OIDC и список администраторов, включить HTTPS на gateway, после этого открывать порт наружу.
Заполнить цены моделей, выпустить API-ключи с лимитами и списком моделей.
Подключить MCP-серверы и закрыть config.yaml на запись, если конфиг управляется из репозитория.