Apollo Router v2.14: federation ops, JWT options, coprocessor polish
Source: Apollo (GitHub release)
Apollo Router remains the gateway most Apollo Federation deployments run in front of their subgraphs. The v2.14.0 release continues a theme that's been visible across the 2.x line: sharper observability, safer auth configuration, and more control when coprocessors sit in the hot path.
Apollo Router v2.14.0 is the latest release on the LTS-supported 2.x line, focused on operational ergonomics and security.
TL;DR
- JSON log formatter tweaks for cleaner ingestion in Loki / Datadog-style pipelines.
- Supergraph path normalization to keep metrics and traces consistent when clients vary URL shapes.
- JWT / JWKS: finer-grained configuration for key rotation and split issuers.
- Coprocessors: optional field-level filtering of response bodies — fewer surprises around PII in custom extensions.
- No breaking changes — drop-in upgrade from 2.13.x.
JSON log formatter improvements
Federation gateways sit between clients and subgraphs, so the gateway's logs are often the first place an SRE looks during an incident. v2.14 polishes the JSON formatter:
- More consistent field names across log levels —
request_id,operation_name,subgraphalign with what tracing already emits. - Reduced verbosity on healthy paths — successful operations no longer pad each line with redundant context.
- Better error stacks — multi-line errors emit as a single JSON entry instead of fragmenting across lines.
The benefit shows up in your log aggregator: dashboards built against the new fields are simpler, and ingestion costs drop slightly because each line is smaller.
Supergraph path normalization
Clients send GraphQL operations to varying URL shapes — /graphql, /api/graphql, /v2/graphql/, sometimes with trailing slashes, sometimes without. Without normalization, metrics and traces fragment by URL, making it hard to answer "how is the UpdateProfile mutation performing?" because the same operation lives under multiple paths.
v2.14 normalizes the supergraph path used in metrics and traces, collapsing trivially-different URLs into a single canonical key. Two effects:
- Cleaner dashboards — one timeseries per operation, not three.
- Smaller cardinality in your metrics backend, which matters at scale.
If you've been working around this with custom Telemetry exporters, you can simplify.
JWT / JWKS configuration
Authentication is one of the easiest places to ship a vulnerability and one of the hardest to test. v2.14 expands the JWT configuration surface:
- Per-issuer JWKS endpoints. When you split federated identity across multiple issuers (one for employees, one for partners, one for end users), each issuer's JWKS URL can be configured independently.
- Key-rotation cadence. Configure how often the router fetches the JWKS, with explicit jitter so you don't get thundering-herd refreshes during a key roll.
- Required claims — add custom required claims per route, validated before the request reaches the supergraph.
The concrete win: rotating a signing key no longer requires a coordinated deploy. Update the JWKS, the router picks up the change on the next refresh cycle.
Coprocessor field-level filtering
Coprocessors are the router's extension mechanism — small services that hook into request and response handling for custom logic (auth header injection, audit logging, data masking). The hook receives the response body, which historically meant the coprocessor could see everything in the response.
v2.14 adds selective response shaping: configure which fields the coprocessor receives, and the router strips the rest before invoking the hook. The pattern matters for two reasons:
- PII protection. A coprocessor that doesn't need access to user emails shouldn't see them.
- Audit scope reduction. Compliance auditors typically prefer "the auth coprocessor only ever saw the operation name and user ID" over "the auth coprocessor saw the entire response and we trust it not to log it".
Configuration is declarative — you list the fields the coprocessor needs, the router enforces.
Operations reminders
A few things worth re-stating with each Router release:
- LTS dates matter. Apollo publishes end-of-support dates for each Federation Router release line. Router 2.x is the current LTS line; if you're on 1.x, treat the vendor EOS dates as a forcing function and plan a migration.
- Read the full changelog before rolling a gateway that terminates customer traffic. Even minor releases occasionally tighten validation in ways that surface latent bugs in upstream subgraphs.
- Stage in a non-production environment with realistic traffic shape — synthetic tests rarely catch the operational regressions that matter.
Migration
v2.14 is drop-in from v2.13.x. No configuration changes are required. To opt into the new features:
- Update the JSON logger configuration if you want the new field names to flow into your existing dashboards (the old names remain available for now).
- Add coprocessor field-filtering to your router configuration.
- Update JWT configuration if you've been waiting for split-issuer support.
Where this connects
If you're tracking the broader GraphQL ecosystem, the September 2025 spec edition and the graphql-js v17 release cover the language and reference implementation; this Router release is the operational layer that makes federation deployments work in practice.
References
Source / further reading: Apollo (GitHub release)