Keep router artifacts on infrastructure you already operate

Cosmo Router can load execution configs and persisted operations from a bucket under your control, which makes it easier to align artifact storage with residency, network, and continuity requirements while keeping composition and publishing flows in Cosmo unchanged.

Most teams choose a bucket that exposes the same API surface as Amazon S3, including software they self-host, and on AWS they prefer attaching an IAM role to the router workload instead of distributing long-lived access keys. When uptime matters, a second registered bucket gives polling a backup path while traffic continues on the last configuration the router successfully loaded.

The problem

Artifact storage has to follow the same rules as the rest of your stack

Regulators and security teams care where configuration artifacts land, whether routers can reach the public internet, and what happens when an object store blips during a deployment. Storage providers let you answer those questions with the same object storage you already trust for other systems.

Data residency rules pin artifacts to a region

A European company may need configuration files to remain in EU infrastructure, even when the payload is not end-user data. Serving those artifacts from a globally distributed CDN can still violate the policy, so teams look for storage they can place in the right region.

Air-gapped environments cannot reach external services

Defense, healthcare, and other locked-down networks often block outbound access to the public internet. If a router had to reach an external CDN on every cold start, that deployment model would simply not be viable.

A single fetch source is a single point of failure

When the artifact store is unreachable, a router that must fetch a fresh config before serving traffic may fail to boot. Operations teams usually want a primary path plus a fallback rather than betting uptime on one endpoint.

Our solution

Bring artifact reads back beside the services that already run in your account

1. In config.yaml, declare a storage provider with the bucket, region, and credentials (or IAM identity) your environment expects.

2. Wire the execution config and persisted operations sections to that provider, and add a second provider entry when you want automatic failover.

3. During CI, run wgc router fetch to obtain the composed execution config from the control plane and publish the artifact into your bucket using your normal object-storage tooling.

4. At runtime the router polls on a fixed interval and hot-reloads when a newer artifact appears, so you do not need to restart the process for each config change.

Default hosting compared with a bucket you configure

How router storage providers work

Define a provider

In config.yaml, add a storage provider block with the bucket, region, and authentication details that match your environment, whether that is a managed cloud bucket or software you host yourself.

Point artifacts at the provider

Reference that provider from the execution config and persisted operations sections so the router knows where to poll, and register an additional provider when you want the router to fall back automatically.

Push artifacts during CI

Use wgc router fetch to download the latest composed execution config from the control plane, then upload it to your bucket as a normal step in the pipeline that already gates releases.

Router polls and hot-reloads

On each polling interval the router checks for a newer artifact, and when one appears it reloads configuration in place so in-flight requests are not dropped for a full restart.

Use cases

Common storage use cases for GraphQL federation

The cards below describe common ways teams wire storage in: keeping artifacts in a chosen geography, operating entirely inside a private network, or pairing a secondary bucket when you need extra resilience during outages.

EU-only data residency

Teams provision a bucket in a European region such as eu-central-1, teach CI to publish the execution config there after each successful composition, and point the router at that bucket so both storage and poll traffic remain inside the geography their policy describes.

Air-gapped infrastructure

Inside an isolated network you can run an object store such as Minio, push artifacts over the internal fabric from CI, and configure routers to read only from that internal hostname so day-two operation never depends on outbound internet access.

High availability with fallback

You can register a primary bucket for normal operation and a secondary bucket that implements the same API; if the primary endpoint fails during a poll, the router retries against the backup so cold starts and reloads degrade gracefully instead of failing outright.

Keep Cosmo for composition while artifacts live next to your workloads

You continue to compose and publish through Cosmo, and the running router simply reads the published artifacts from object storage that already meets your security and residency expectations.

FAQ

Storage providers

• Which storage backends does the Router support?
• Do I need the Cosmo control plane if I use custom storage?
• How does Cosmo Router authenticate to my storage bucket?
• How quickly does a new GraphQL router config take effect after publishing?
• How are persisted operations named and organized in the storage bucket?

For deeper technical detail, see the storage providers documentation.