Isolated work
Create an isolated feature branch. Main stays clean and locked.
Developers work in branches. Main is read-only in Hub. Changes made in Hub go through a proposal.
Start Shipping SafelyHubShip Without Breaking
Ship API changes
without breaking your clients
Replace deployment anxiety with automated confidence. Hub checks breaking GraphQL schema changes against real production traffic, blocks approval when your Cosmo deprecation rules fail, and shows complexity changes for the operations you select before you merge.
Know what you'll break. Before you ship.
Changes made in Hub go through a proposal. Each proposal runs Cosmo schema checks, including a client traffic check when a change is breaking.
Traffic-aware validation
Breaking changes checked against real client operations. See which operations and clients are affected before you merge.
Deprecation enforcement
Opt-in graph pruning rules fail a check when a field is deleted without deprecation. The client traffic check fails when clients still use it.
Performance visibility
Optimizer shows query plans and complexity. Proposals compare complexity for the operation collections you select.
Protected main
Main is read-only in Hub. Invalid compositions never reach it.
The Problem
Every schema change is a bet. Most teams are flying blind.
A field gets renamed. A type gets moved. Someone deletes something that "looked unused." Then production breaks and you spend hours figuring out which client was depending on that field. The problem isn't your engineers — it's that the tools give them no way to know what they're breaking until it's already broken.
Explore platform01
"I thought nothing was using that"
No visibility into which clients hit which fields. Deletions and renames become a game of chance.
02
Deployment anxiety
Every merge feels risky. Teams delay changes or skip deprecation and hope for the best.
03
Late-night rollbacks
Breaking changes reach production before anyone notices. You find out when clients break.
FAQ
Deprecation and breaking changes
How do I require deprecation before a field is deleted?
Use Cosmo's graph pruning linter. On the Lint Policy page, pick the namespace, turn on graph pruning, and enable the REQUIRE_DEPRECATION_BEFORE_DELETION rule. Set its severity to Error so a violation fails the check. Warning only flags it. You can also set a grace period. It is not a minimum time a field must stay deprecated: it gives fields changed in a publish time before the rules are enforced on them in checks. The rules are off until you turn them on. In Hub, the result shows up as the Pruning Errors check on each proposal.
How do I stop a field deletion while clients are still using it?
Removing a field is a breaking change, so Cosmo runs the client traffic check, also called the operations check. It tests the change against the operations your clients sent in the last 7 days by default. You can change that window per namespace in Policies, up to your plan's limit. If any client used the field, the check fails and lists the affected operations and clients. Hub keeps the Approve button off until all checks pass. The check needs your routers to send schema usage metrics, which they do by default. It is separate from graph pruning.
Can I ship an intentional breaking change?
Yes. If no client used the affected fields in the traffic window, the client traffic check passes. Other checks and owner approval still apply. If clients still use them, Cosmo Studio has two documented options. A manual override forces the change through, even when every check except composition is red. The docs say this currently requires the GitHub integration. Operation check overrides tell future checks to ignore specific breaking changes for an operation, or the whole operation. They apply across all graphs in the namespace, do not change the current check run, and do not affect composition, breaking change detection, or linting. Composition errors can never be overridden.
Related pages
How It Works
The workflow your team actually needs.
Branch, design, propose, review, and publish, with checks and owner review before approval.
Real-time validation
Modify the schema on the canvas. Validation catches errors as you go.
Change types and fields on the canvas. Hub validates as you edit: naming rules, type compatibility, duplicate field and argument names, and circular references. It blocks invalid configurations, so you fix issues before opening a proposal.
Start Shipping SafelyChecks against production
Open a proposal. Hub runs schema checks and client traffic analysis.
Hub runs Cosmo schema checks on each proposal. When a change is breaking, the client traffic check tests it against the operations your clients sent in the last 7 days (the default, set per namespace and capped by plan). You see which operations are affected, so you can decide whether the breakage is intentional. Proposals need the graph connected to the Cosmo schema registry, with proposals configured in Cosmo.
Start Shipping SafelyRequired sign-off
Affected type and subgraph owners become required reviewers.
Once you assign owners, Hub adds the owners of affected types and subgraphs as required reviewers. All discussion threads must be resolved before approval. Nothing merges until the right people sign off.
Start Shipping SafelySafe to ship
Once approved, publish the changes. Main stays in sync with production.
Publish the approved proposal to the Cosmo schema registry. Hub updates main from the registry, so it always matches production.
Start Shipping SafelyEverything your graph needs to ship safely
Traffic-aware checks, deprecation rules, and composition guardrails.
Traffic-Aware Validation
See which operations a change would break
Your routers send schema usage data to Cosmo. When a proposed change is breaking, the client traffic check tests it against the operations your clients sent in the last 7 days. That is the default; you can change it per namespace, up to your plan's limit. You see which operations are affected, so you can decide whether the breakage is intentional.
No guesswork. No "I thought nothing was using that."
Affected operations
LegacyReportUses removed field
AdminExportUses removed field
Client traffic check fails while these clients use the field
Composition Guardrails
Invalid compositions never reach main.
As you design on the canvas, Hub validates as you edit: naming rules, type compatibility, duplicate field and argument names, and circular references. It blocks invalid configurations and shows a clear error. When you open a proposal, the Cosmo Composes check confirms your changes compose.
A proposal can't be approved until it passes every check.
Real-time validation
No circular referencesPass
Naming rulesPass
Duplicate argument: userIdFail
Fix errors before opening a proposal
Deprecation & Grace Periods
Catch deletions that skip deprecation or break clients.
Two separate Cosmo checks cover this. Graph pruning rules are opt-in. Turn on REQUIRE_DEPRECATION_BEFORE_DELETION with Error severity, and a check fails when someone deletes a field that was never deprecated. A grace period you set gives changed fields time before the rules apply.
The client traffic check runs when a change is breaking. If clients used the field in the last 7 days (the default window), the check fails and lists the affected operations and clients.
The checks do the policing, so your platform team can stop playing traffic cop.
Schema checkphoneNumber
Client trafficFailed
Pruning: not deprecatedFailed
ComposesPassed
Traffic window: last 7 days (default)
Get Started
Ship with confidence. No more deployment anxiety.
Changes made in Hub go through a proposal. Each proposal runs Cosmo schema checks, including a client traffic check when a change is breaking.
WunderGraph Hub: collaborative, visual, and safe to ship.
Product
Resources
Related Projects
Certified & Compliant
SOC 2 Type II
HIPAA
ISO 27001© 2026 WunderGraph, Inc. All rights reserved.