Is Cosmo Router actually open source, or is it open-core?

The router is Apache 2.0 licensed. The same binary runs in Cosmo Cloud and in your own infrastructure. There is no premium router build held back for paid tiers.

Can I run the router without the Cosmo Control Plane?

Yes. The router can run with a static execution config file and no control plane connection.

Does it support Apollo Federation v1 and v2?

Yes. The router implements both Federation v1 and v2.

What happens if the Cosmo Control Plane is unreachable?

The router keeps serving traffic from its cached execution config. How it reconnects or backs off toward the control plane is covered in the router documentation.

How is it different from Apollo Router?

Cosmo Router is Apache 2.0 licensed, built in Go on graphql-go-tools. Config is hot-reloaded from a CDN, and the router operates independently of the control plane at request time.

The router itself is free and open source. Cosmo Cloud pricing covers the managed control plane, schema registry, and observability. See the pricing page.

GraphQL Federation Router | Cosmo by WunderGraph

The problem

Federation gateways should scale with your graph, not fight it

Planning cost, licensing, and deploy friction compound as teams ship more subgraphs.

Gateways slow down as the graph grows

Query planning is expensive, and a gateway that re-plans every request struggles once traffic and schema complexity climb. Latency creeps up, and the gateway becomes the thing you tune around instead of the thing you trust.

Proprietary licensing locks you in

Some federation gateways ship under a license that limits what you can run, where, and for how long. The roadmap is someone else's. So is the pricing.

Schema changes cause downtime

Updating a federated schema often means restarting the gateway or draining traffic. That is a deploy coordination problem no one wants to solve on a Friday.

Our solution

One router for your whole federated graph: fast, open source, and always up

Cosmo Router is an open-source GraphQL federation router built in Go that routes queries across your subgraphs, caches query plans for speed, and reloads configuration live so your API stays up when schemas change.

How it behaves at runtime

Fetches the current execution config from a CDN using its graph API token.
Builds an optimized query plan for each operation and caches it so repeat traffic skips replanning.
Routes requests to subgraphs and aggregates responses.
When the composed schema updates, the router discovers it on the next CDN poll (default every 15 seconds, configurable; pull-based, not push). It swaps planners without restart. The plan cache is rebuilt cold on the new engine, so expect a short window of higher planning latency until hot paths warm again.
The router runs independently: it registers with the Cosmo Control Plane for health reporting, but does not depend on the control plane to serve requests. If the control plane is unreachable, the router keeps serving traffic from its cached config.

Open source. Same binary in cloud and self-hosted.

Federation router

Before & After

Before Cosmo	With Cosmo
Gateway re-plans every query, latency grows with load	Query plans cached for reuse, planning cost paid once
Proprietary license dictates where and how you deploy	Apache 2.0: run it anywhere, fork it if you want
Schema deploys require gateway restarts or traffic drain	Hot-reload from CDN, engine swapped in place
Gateway stops serving if the control plane goes down	Router keeps serving from cached config regardless

Operations

What ships with the router

Beyond federation routing and CDN-driven hot reload, you get hooks teams expect in production: HTTP endpoints for Kubernetes health checks, GraphQL Playground for trying queries against your graph, OpenTelemetry hooks for traces, and configurable logging, metrics, and tracing (exact flags live in the docs).

How the federation router runs

01

CDN or file: your topology.

Pull the execution config

Router fetches the current execution config from the CDN using its graph API token. A static file is also supported for air-gapped deployments.

02

Federation v1 and v2.

Build the query planner

Router builds an optimized query planner from the federated schema. For each operation, it decides which subgraphs to call and in what order.

03

Planning cost paid once per cached operation.

Serve requests with cached plans

Cache hit: execute. Cache miss: plan, cache, execute. Responses aggregated on the unified endpoint.

04

Graceful handoff, no restart.

Hot-reload on config change

Router polls the CDN on a configured interval. On a new valid config it builds a new planner and swaps the engine live. In-flight requests finish on the old engine; new ones run on the new.

Use cases

Where teams deploy Cosmo Router first

Production gateway, zero-downtime schema publishes, and air-gapped self-hosting.

Production federation gateway

Platform

Teams publish schema updates via CLI. The control plane composes the federated schema and pushes it to the CDN. The router picks up the new config on its next poll and swaps its engine. No restart. No client disruption.

Zero-downtime schema updates

CDN poll

Developers push schema changes without coordinating router restarts. The router polls for updates, builds a new query planner, and transitions traffic live. In-flight requests finish on the old engine.

Self-hosted, air-gapped federation

Static config

Deploy with a static execution config instead of CDN polling. No outbound dependency on Cosmo Cloud at request time. Full federation capabilities inside isolated infrastructure.

Run the open-source federation router

Apache 2.0. Go. Cached plans. Hot config reload.

Start Free Read the Docs

Run GraphQL federation at scale without vendor lock-in