Manage every federated service from one CLI and Studio

Create, publish, update, and delete subgraphs with label-based composition rules and namespace isolation — no ad-hoc configuration drift.

Every operation available via CLI for automation. Studio for visual management.

The problem

Subgraph operations without unified tooling create drift

Registering services, publishing schema changes, managing labels, and retiring old subgraphs each require different tools when there is no unified system — and inconsistencies compound over time.

Subgraph configurations drift across environments

When teams manage routing URLs, labels, and schema versions manually across dev, staging, and production, inconsistencies accumulate. A staging subgraph points to one URL; production points to another. No one notices until a query fails.

Deleting a subgraph without checking impact causes cascading failures

Removing a subgraph that other parts of the federated graph depend on breaks composition. Without pre-deletion impact analysis, teams find out after the damage is done.

No visibility across teams without central management

Which subgraph is registered for which federated graph? Which schema version is currently published? Without central management, answering these questions requires talking to each service team individually.

Our solution

Complete lifecycle control in five operations

Cosmo's Subgraph Management gives teams complete lifecycle control over federated services. Create, publish, update, check, and delete subgraphs through a unified CLI and Studio interface — with label-based composition rules and namespace isolation for multi-environment workflows.

1. Create registers the subgraph in the control plane with a name, routing URL, and label set.
2. Publish pushes the schema file and triggers automatic composition with all matching federated graphs.
3. Check validates composition impact before publishing — and flags deletion impact with the --delete flag.
4. Update changes routing URLs or labels without republishing the schema.
5. Delete removes the subgraph after a pre-deletion impact check confirms no critical dependencies remain.

Subgraph management

Before & After

How labels control composition

• Labels are key-value pairs assigned to each subgraph (e.g., team=backend).
• Federated graphs define label matchers. A subgraph joins any federated graph whose matchers include its labels.
• Publishing a schema triggers composition with all matching federated graphs automatically.
• Updating labels with wgc subgraph update changes graph membership without touching the schema.

Key benefits

Complete lifecycle control for your federated services

All five operations included on Free, Pro, and Enterprise.

Full lifecycle control from one place

Lifecycle

Create, publish, update, and delete subgraphs through a unified CLI and Studio interface. Every operation targets the same control plane, so state is consistent across all environments.

Label-based composition ties subgraphs to federated graphs

Labels are key-value pairs assigned to subgraphs (e.g., team=backend). Federated graphs define label matchers. A subgraph joins any federated graph whose matchers include its labels — no manual wiring required.

Namespace isolation for multi-environment workflows

Dev, staging, and production run in separate namespaces. The same subgraph name can exist in each namespace independently. Publish to staging with --namespace staging; promote to production with --namespace production.

Validate impact before any change lands

Run wgc subgraph check before publishing to catch composition errors and breaking changes. Run wgc subgraph check --delete to see exactly which federated graphs would be affected before removing a subgraph.

Automation-friendly via CLI and API

Every subgraph operation — create, publish, update, check, delete — is available as a CLI command. Integrate into CI/CD pipelines to automate schema promotion and catch problems before they reach production.

How subgraph management works

01

Create the subgraph

Run wgc subgraph create with a name, routing URL, and label set. This registers the subgraph in the control plane. For event-driven subgraphs, add the --edg flag instead of a routing URL.

02

Publish the schema

Run wgc subgraph publish with a schema file. The control plane triggers composition with all federated graphs whose label matchers include the subgraph's labels.

03

Check before publishing

Run wgc subgraph check with the proposed schema file to validate composition impact and detect breaking changes before anything is published.

04

Update metadata

Use wgc subgraph update to change the routing URL or label set without republishing the schema. Useful when a service moves domains or team ownership changes.

05

Delete safely

Run wgc subgraph check --delete to see which federated graphs depend on the subgraph. After confirming no critical dependencies remain, run wgc subgraph delete.

Use cases

New subgraph registration

A team launches a new microservice and needs to join the federated graph. They run wgc subgraph create products --label team=backend --routing-url http://products:4001/graphql, then publish the initial schema with wgc subgraph publish products --schema ./schema.graphql.

Safe schema update

A developer needs to add new fields and deprecate old ones. They run wgc subgraph check products --schema ./new-schema.graphql first. If checks pass, they run wgc subgraph publish products --schema ./new-schema.graphql.

Environment promotion

A schema change tested in staging is ready for production. They publish with wgc subgraph publish products --namespace production --schema ./schema.graphql. Labels match production federated graphs for automatic composition.

Subgraph retirement

A legacy subgraph is being deprecated. They run wgc subgraph check products --delete to see the impact on all connected federated graphs. After confirming no critical dependencies, they run wgc subgraph delete products.

When to use subgraph management

When to use

• You are registering a new microservice in a federated GraphQL architecture.
• You want automated schema promotion across dev, staging, and production namespaces.
• You need to safely remove a subgraph and verify there are no breaking dependencies first.

Requirements

• Namespace access with appropriate permissions in Cosmo.
• A routing URL accessible from the router — for non-Event-Driven Graph subgraphs.
• A schema file in GraphQL SDL format for publish operations.

Start managing subgraphs in minutes

One CLI. Full lifecycle control. Free to start.

Ready to go deeper?

Full CLI reference for every subgraph operation.