# 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 | Before Cosmo | With Cosmo | | --- | --- | | Manual subgraph registration | CLI/API-driven creation | | Ad-hoc schema file distribution | Centralized publish workflow | | Unclear subgraph-to-graph relationships | Label-based composition rules | | Risky subgraph removal | Pre-deletion impact analysis | ### 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.