What is WunderGraph?
WunderGraph is the company behind Cosmo, an open-source GraphQL federation platform, and Hub, a design and governance layer for federated schema changes.
What is WunderGraph Cosmo and when should teams use it?
WunderGraph Cosmo is an open-source GraphQL federation platform: router, schema registry, composition checks, analytics, and distributed tracing in one stack, licensed Apache 2.0. Teams use it when multiple teams own parts of one GraphQL API and need to compose, run, and observe that graph without vendor lock-in. It runs fully self-hosted or with a managed control plane. Learn more about Cosmo.
What is WunderGraph Hub?
WunderGraph Hub is the design and governance layer for federated GraphQL schemas, and it is generally available. Developers propose schema changes on a collaborative canvas, Hub validates changes as you edit, checks every proposal for composition and against observed production traffic, and requires review from every type owner and subgraph owner a change affects. After a proposal is approved and merged, your CI publishes the schema to the registry and Hub marks the proposal as published. Learn more about Hub.
What is Cosmo Router?
Cosmo Router is the runtime of the Cosmo platform: a Go-based GraphQL federation router, Apache 2.0 licensed, built on graphql-go-tools. It plans and executes federated queries across subgraphs and ships with caching, rate limiting, request deduplication, a cache warmer, and native OpenTelemetry and Prometheus support. Learn more about the Router.
What is Cosmo Studio and what does it do?
Cosmo Studio is the web interface of the Cosmo platform. It is where teams manage the schema registry, run schema checks, browse the schema explorer and changelog, analyze traces and field usage, and administer access: RBAC, groups, SSO, and SCIM. Studio works with both Cosmo Cloud and self-hosted deployments. Learn more in the Studio docs.
What is Cosmo Connect and when should teams use it?
Cosmo Connect federates non-GraphQL backends into your graph over gRPC. It compiles an Apollo-compatible subgraph schema into a protobuf definition, and teams implement that contract in any gRPC language such as Go, Java, or C#. Use it when backend teams run REST, gRPC, or SOAP services and you want them in the federated graph without those teams writing GraphQL subgraphs. Learn more about Connect.
What is Cosmo Streams?
Cosmo Streams connects Cosmo Router directly to Kafka, NATS/JetStream, or Redis for real-time GraphQL subscriptions. Backend services stay HTTP-only and stateless; the Router holds subscriber connections and applies per-subscriber filtering centrally. The Router does not check whether a client may subscribe to a given topic; that authorization is written as a custom module. Learn more about Streams.
How do Cosmo, Hub, and Connect fit together?
Cosmo is the federation platform: registry, router, and observability for running a federated graph. Hub sits in front of it as the design and governance layer, where schema changes are proposed, validated, and approved before they reach the registry. Connect extends the graph downward, bringing REST, gRPC, and SOAP backends into federation over gRPC. Design in Hub, run on Cosmo, connect anything with Connect. Learn more about the platform.
Is WunderGraph the same as Cosmo?
Not exactly: WunderGraph is the company, Cosmo is its open-source GraphQL federation platform. WunderGraph also builds Hub, the schema design and governance layer. If you see "WunderGraph Cosmo," that is the federation platform; older content sometimes says just "WunderGraph" for products that have since been renamed or retired. Learn more about Cosmo.
What happened to the WunderGraph BFF SDK and WunderNode?
Both are retired. The WunderGraph BFF SDK is sunset and no longer recommended for new projects, and WunderNode, the 2021 product, no longer exists. Everything WunderGraph builds now is part of the Cosmo platform and Hub, and teams on legacy WunderGraph products should move to Cosmo. See the migration guide.
Pricing, licensing, self-hosting
Cosmo is Apache 2.0 and free to self-host. Cosmo Cloud has a free tier for up to 10 million requests a month plus paid plans, Managed On-Premises and Enterprise are also available, and Hub Pro costs $49 per user per month.
How much does WunderGraph Cosmo cost?
Cosmo is free to self-host: the entire platform is open source under Apache 2.0, with no usage-based license fees. Paid options cover running it for you: Cosmo Cloud plans, Managed On-Premises (fully managed inside your own AWS, GCP, or Azure account on flat-rate pricing), and Enterprise agreements with SLAs and support. See current pricing.
Can I self-host Cosmo for free? What are the limits?
Yes. The full Cosmo platform, including the router, control plane, and studio, is Apache 2.0 open source, so you can run it in your own infrastructure at any scale without license fees. The practical limit is operational: you run and upgrade the components yourself. See what self-hosting includes.
What license is Cosmo under, and what does Apache 2.0 vs ELv2 mean in practice?
Cosmo is licensed Apache 2.0; Apollo GraphOS Router is source-available under ELv2. In practice: Apache 2.0 lets you use, modify, and run Cosmo in production, including commercially, with no restrictions on offering it as part of your own services. ELv2 is not an OSI-approved open-source license and restricts offering the software as a managed service. Check each license text for your case. Learn more.
Is there a managed option? What's the difference from self-hosted?
Yes, two. Cosmo Cloud runs the control plane (registry, studio, analytics) as a managed service while your routers run wherever you choose. Managed On-Premises goes further: WunderGraph runs the full platform inside your own AWS, GCP, or Azure account, including managed upgrades, PostgreSQL, ClickHouse, routers, and OTEL collectors, on flat-rate pricing. Self-hosted open source means you run everything yourself. Compare plans.
How do I subscribe to Cosmo?
Sign up for Cosmo Cloud directly from the pricing page, or talk to sales for Managed On-Premises and Enterprise plans. Self-hosting needs no subscription at all: the platform is Apache 2.0 and you can deploy it from the public repositories today. Get started on the pricing page.
What does Hub cost? Is it part of Cosmo?
Hub is a separate product from Cosmo: it is the schema design and governance layer, and it integrates with the Cosmo schema registry. Hub Pro is $49 per user per month, with a 14-day trial. Enterprise is custom. Hub is not bundled into Cosmo Cloud or self-hosted Cosmo plans. Learn more about Hub.
How do I migrate from Apollo GraphOS or Apollo Router to Cosmo?
Migration is directive-compatible: Cosmo supports Apollo Federation v1 and v2, so subgraphs typically move without schema rewrites, and Cosmo Studio includes a one-click migration from Apollo GraphOS. Customers have done it fast: TravelPass reconfigured everything in about a day, and Soundtrack Your Brand set up and ran Cosmo in about a day's work after deciding in a week. Note that Apollo Router 1.60+ dropped Federation v1 support; Cosmo still supports both. See the migration guide.
Comparisons
Cosmo differs from Apollo GraphOS mainly in licensing and Federation v1 support: the full Cosmo platform is Apache 2.0, Apollo Router is source-available under ELv2, and Cosmo still runs Federation v1 supergraphs that Apollo Router 1.60 and later do not.
How is Cosmo different from Apollo GraphOS?
Cosmo is the open-source alternative to Apollo GraphOS: the full federation platform, including router, schema registry, checks, and analytics, is Apache 2.0, while GraphOS is a commercial platform whose router is source-available under ELv2. Cosmo runs fully self-hosted with no license keys, and it still supports Federation v1 as well as v2. Read the full comparison.
Cosmo Router vs Apollo Router: what's the practical difference?
Two differences show up in practice. License: Cosmo Router is Apache 2.0; Apollo Router is ELv2 source-available. Federation support: Apollo Router 1.60 and later no longer run Federation v1 supergraphs; Cosmo Router supports v1 and the v2 directives through Federation 2.5. Compare the routers.
How does Hub compare to Apollo GraphOS for schema governance?
Hub is a dedicated design-time governance product. It protects the main branch, validates changes as you edit on a collaborative canvas, checks every proposal for composition and against observed production operations, and requires approval from every affected type owner and subgraph owner. A proposal that would break operations clients still send fails its client traffic check, and Hub keeps it from being approved until every check passes. Learn more about Hub.
Is there an alternative to Apollo schema proposals?
Yes: WunderGraph Hub. Hub is built around proposals: schema changes are drafted on a collaborative canvas, validated for composition in real time, checked against real production traffic, and gated on approval from every type owner and subgraph owner the change affects. Deleting a field that clients still use fails the check, and Cosmo graph pruning can flag fields deleted without a prior deprecation. Learn more about Hub.
Cosmo vs GraphQL Hive: schema registry and router
Cosmo is a single platform: schema registry, composition checks, analytics, and a high-performance Go router, all Apache 2.0 and run as one stack. GraphQL Hive is The Guild's MIT-licensed schema registry, typically paired with Hive Gateway or Hive Router from their toolchain. If you want registry and runtime designed and shipped together, that is the difference. Learn more.
Grafbase vs WunderGraph Cosmo
Both offer GraphQL federation tooling; the practical difference is scope and maturity of the self-hosted open-source path. Cosmo's entire platform is Apache 2.0, runs at documented production scale (eBay routes 100% of its federated GraphQL traffic through Cosmo), and supports Federation v1 and v2. Learn more.
ChilliCream Nitro vs Cosmo Router
ChilliCream Nitro is an API operations platform from the .NET ecosystem around Hot Chocolate; Cosmo Router is a standalone Go binary that is language-agnostic about your subgraphs. Cosmo is Apache 2.0, supports Apollo Federation v1 and v2 at the directive level, and ships OpenTelemetry and Prometheus natively. Learn more.
Is Cosmo an alternative to Hasura or AWS AppSync for federation?
For federation, yes, and the fit differs. Hasura's core strength is generating GraphQL over databases; AppSync is AWS's managed GraphQL service. Cosmo is built specifically for GraphQL federation across team-owned subgraphs: open-source router and registry, composition checks, and Federation v1/v2 compatibility, self-hosted or managed. If your problem is many teams composing one graph, that is Cosmo's home turf. Read the AppSync comparison.
Apollo Rover vs wgc: what does the Cosmo CLI cover?
wgc is Cosmo's CLI and covers the full platform: creating, publishing, and checking subgraphs and federated graphs, composing router configs, managing routers and tokens, schema contracts, feature flags and feature subgraphs, gRPC services for Connect, proposals, and persisted operations. Install it with npm install -g wgc or run it via npx wgc. See the CLI reference.
Apollo Connectors vs Cosmo Connect
They solve the same problem differently. Cosmo Connect compiles an Apollo-compatible subgraph schema into a protobuf definition, and your team implements that gRPC contract in any gRPC language as a standalone service, or in Go or TypeScript as a router plugin. It is not a REST-to-GraphQL field mapping. Apollo Connectors take the declarative route, mapping REST responses to schema fields. Learn more about Connect.
Customers & proof
eBay, SoundCloud, NerdWallet, K Health, and other companies run GraphQL federation in production on Cosmo, each running the Cosmo Router in its own infrastructure.
Who uses WunderGraph Cosmo?
Companies running GraphQL federation in production on Cosmo include eBay, SoundCloud, Acoustic, On The Beach, K Health, TravelPass Group, Luxury Presence, Soundtrack Your Brand, NerdWallet, and PemPem. They span ecommerce, streaming, healthcare, travel, fintech, and real estate, from scale-ups to global marketplaces, most of them running self-hosted routers in their own infrastructure. Read their stories.
Which companies run GraphQL federation at scale on Cosmo?
eBay runs one of the largest: 100% of its federated GraphQL traffic is on Cosmo, sustaining hundreds of thousands of requests per second in production. SoundCloud serves one of the world's largest open audio platforms through Cosmo Router. On The Beach averages 4 billion monthly clicks across its platform, and K Health runs federation under HIPAA with nearly 10 subgraphs. Read the case studies.
What are real-world results from migrating to Cosmo Router?
Published results: SoundCloud cut provisioned CPU across its architecture by 86% (600 to 80 vCPUs, with the Cosmo Router fleet at 40 of the 80) and saw a high-traffic query drop from 171ms to 94ms at P95. eBay handles the same production traffic with 80% fewer router nodes and about 50% lower router memory. NerdWallet's slowest query planning went from over 10 seconds to under 1 second with the Cache Warmer. Read the case studies.
Where can I read GraphQL federation case studies?
On the WunderGraph customers page, which links case studies from eBay, SoundCloud, Acoustic, On The Beach, K Health, TravelPass, Luxury Presence, Soundtrack Your Brand, NerdWallet, and PemPem. Browse the case studies.
Capabilities in brief
Cosmo covers the federation runtime and what connects to it: a router compatible with Apollo Federation v1 and the v2 directives through Federation 2.5, Cosmo Connect for gRPC, REST, and SOAP backends, Cosmo Streams for event-driven subscriptions, an MCP Gateway for AI agents, and native OpenTelemetry and Prometheus support.
Is Cosmo compatible with Apollo Federation v1 and v2?
Yes, both, at the directive level. Cosmo's compatibility matrix lists every Federation v1 directive, and the v2 directives through Federation 2.5, as supported. This matters for migration: Apollo Router 1.60 and later dropped Federation v1 supergraph support, so v1 graphs moving off Apollo keep working on Cosmo without a schema rewrite. See migration details.
Can Cosmo federate REST, gRPC, and SOAP services?
Yes, through Cosmo Connect. gRPC services join the graph natively: Connect compiles a subgraph schema into a protobuf contract your team implements. Existing REST and SOAP APIs can be wrapped without writing full GraphQL subgraphs. Implementations run as router plugins for lowest latency or as standalone gRPC services your teams scale independently. Learn more about Connect.
Does Cosmo have an MCP gateway for AI agents?
Yes. Cosmo Router has a built-in MCP server that exposes your GraphQL API to AI models and agents, with OAuth 2.1 support and operation-level control over what agents can call. It is off by default and enabled through the router's mcp config block. Learn more about the MCP Gateway.
What observability does Cosmo ship out of the box?
OpenTelemetry and Prometheus support are native to the Router, no sidecars or plugins required. On top of that: distributed tracing, access logs, Advanced Request Tracing for per-request execution detail, and Studio analytics covering traces, metrics, schema field usage, and client identification. Learn more about observability.
How does Cosmo deploy: Kubernetes, Helm, bare metal?
All of the above. The Router is a single Go binary, deployable via Docker, Kubernetes with an official Helm chart, Terraform (including AWS Fargate), an AWS Lambda-optimized binary, or straight onto a VM. Config hot-reloads from the CDN by polling (10-second default interval) without downtime. See the deployment docs.
Does Cosmo support GraphQL subscriptions at scale?
Yes. The Router supports five subscription protocols: graphql-ws, Server-Sent Events, Multipart HTTP, subscriptions-transport-ws (legacy), and absinthe (legacy). For event-driven scale, Cosmo Streams connects the Router directly to Kafka, NATS/JetStream, or Redis, so backend services stay stateless and HTTP-only while the Router manages subscriber connections and per-subscriber filtering. Learn more about Streams.
What is the wgc CLI?
wgc is the command-line interface for Cosmo. Teams use it to create, publish, and check subgraphs, compose and manage federated graphs, run schema checks in CI, manage router tokens and configs, schema contracts, feature flags, proposals, and Connect gRPC services. Install with npm install -g wgc or run via npx wgc. See the CLI reference.
Security & procurement
WunderGraph has achieved SOC 2, Cosmo Studio supports SSO, SCIM, and RBAC, and a self-hosted router keeps request data inside your own infrastructure.
Is WunderGraph SOC 2 compliant?
WunderGraph maintains SOC 2 Type II certification, and self-hosting narrows your audit surface further: the data plane runs entirely in your infrastructure. See compliance details.
Does Cosmo support SSO and SCIM?
Yes. Studio supports SSO with documented setup for Okta, Auth0, Keycloak, and Microsoft Entra, plus organization- and namespace-level login method controls on the Enterprise plan. SCIM provisioning is supported, with Okta guides including the OIN version (on Cosmo Cloud, SSO starts on the Scale plan and SCIM is an Enterprise feature), so user access follows your identity provider automatically. Learn more about SSO.
Does Cosmo have RBAC and team permissions?
Yes. Studio ships role-based access control with groups and group rules, API keys scoped through group assignment, and an audit log covering organization activity. Access is managed centrally and can be driven from your IdP via SSO and SCIM. On Cosmo Cloud, RBAC starts on the Scale plan. Learn more about RBAC.
What data leaves my infrastructure when self-hosting Cosmo?
Fully self-hosted open-source Cosmo, including the control plane, runs entirely in your infrastructure, so nothing leaves it. When you pair self-hosted routers with Cosmo Cloud, the routers send anonymized schema and operation metadata and telemetry to the control plane, not your request or response payloads. Cosmo Cloud retention is 30 days for telemetry and 90 days for schema usage data, depending on plan. See self-hosting details.
Can Cosmo run in regulated industries (PCI, healthcare)?
It already does. TravelPass Group runs Cosmo's self-hosted router for direct control over its data and PCI compliance. K Health runs federation on Cosmo under HIPAA. eBay's deployment passed full internal security and compliance review. The pattern is the same: self-hosted routers keep regulated data inside your boundary while the platform handles federation. Read the TravelPass story.
How does Cosmo handle field-level authorization?
Through Federation's access-control directives, enforced at the Router. @authenticated requires an authenticated request, and @requiresScopes enforces scope-based authorization (outer list OR, inner list AND). Both apply at the type-system level on enums, fields, interfaces, objects, and scalars, and require Federation v2.5 or later. Note @authenticated is authentication, not role-based access control. See the directive docs.
Fundamentals
An MCP gateway connects AI agents to APIs over the Model Context Protocol, schema governance software checks and reviews schema changes before they reach production, and a federated architecture combines independently developed services into one API. Cosmo Router includes an MCP Gateway, WunderGraph Hub governs schema changes, and Cosmo runs federated GraphQL.
What is an MCP gateway?
An MCP gateway connects AI agents to APIs or tools through the Model Context Protocol (MCP). In Cosmo, the MCP Gateway is an opt-in Cosmo Router feature that turns GraphQL operations you define in .graphql or .gql files into MCP tools, checking each one against your schema when it loads. That makes it persisted operations for agents: through MCP, an agent can only run the operations you defined. Running arbitrary operations (mcp.enable_arbitrary_operations) and exposing the full schema (mcp.expose_schema) are both off by default. OAuth 2.1 support, also off by default, can control which agents connect and which tools each one can call. Learn more about the MCP Gateway.
What is API governance?
API governance is the set of standards, policies, and practices that direct how an organization develops, deploys, and uses its APIs. Common practices include consistent design, versioning, and automated checks. For federated GraphQL, WunderGraph Hub applies governance to schema changes: changes made in Hub go through proposals, and once owners are assigned, every affected type owner and subgraph owner must approve. Cosmo schema checks run on each proposal and can run in CI with wgc subgraph check, testing composition, breaking changes, and lint rules when enabled, and fail a change that breaks operations real clients still send. Read the Hub governance docs.
What is schema governance software?
Schema governance software enforces schema governance: the checks and review rules that catch a breaking schema change before it reaches production. WunderGraph Hub is schema governance software for federated GraphQL. Teams propose changes on a shared canvas, and Hub validates as they edit, including GraphQL naming rules, type compatibility, duplicate field and argument names, and circular references. Hub proposals require the graph to be connected to the Cosmo schema registry, with proposals enabled in Cosmo. When a proposal contains a breaking change, the Cosmo client-traffic check tests it against the operations clients sent in the last 7 days by default. Once owners are assigned, every affected type owner and subgraph owner must approve. An approved proposal is then ready to publish to the registry. Read the Hub governance docs.
What is a federated architecture?
In GraphQL, a federated architecture combines multiple independently developed services, called subgraphs, into one unified API called a supergraph. Typically one team owns each subgraph, and a router builds a query plan and orchestrates requests across the subgraphs, so clients query the whole system as one schema. WunderGraph Cosmo is an open-source (Apache 2.0) platform for this: Cosmo Router serves the supergraph, and Cosmo's schema registry and schema checks test that subgraphs still compose before changes ship. Learn more about GraphQL federation.
How-to questions
Expose GraphQL to AI agents through approved operations instead of open queries, scale subscriptions by routing events through a broker, and catch breaking schema changes with owner review and checks against real client traffic. Cosmo Router and Cosmo Streams handle the first two, and WunderGraph Hub and Cosmo schema checks handle the third.
What is the safest way to expose a GraphQL API to an LLM agent?
Expose operations, not the schema: give the agent a fixed set of approved operations instead of letting it write its own queries. Cosmo's MCP Gateway works this way. Through MCP, Cosmo Router runs only the GraphQL operations you define as tools, and mcp.enable_arbitrary_operations and mcp.expose_schema stay off unless you turn them on. You can also drop mutations from your tools with mcp.exclude_mutations. With OAuth 2.1 on, scopes control what each agent can call, down to per-tool scopes taken from @requiresScopes in your schema. The safelist covers the MCP endpoint only. Cosmo Router's GraphQL endpoint accepts any operation by default, so lock it down separately if agents can reach it. The MCP Gateway sends its tool calls to that same endpoint, so test your tools after you lock it down. Read how to safelist GraphQL operations for AI agents.
How do persisted operations protect a GraphQL API from AI agents?
Persisted operations let you turn your API into a safelist. You register the operations you trust ahead of time with wgc operations push, and Cosmo validates them against your schema. With security.block_non_persisted_operations.enabled set to true and APQ disabled (automatic_persisted_queries.enabled: false), Cosmo Router rejects any request that isn't a registered operation, so an AI agent can only run operations you approved. Clients identify the operation by its registered ID: a SHA-256 hash for plain .graphql files, or the ID from your Apollo or Relay manifest. Custom IDs that aren't SHA-256 hashes need APQ off. Automatic Persisted Queries (APQ) is a different feature: it caches whatever clients send to save bandwidth, and it isn't a security control. Keep APQ off when you enforce persisted operations, because it lets clients register their own queries. The Cosmo MCP Gateway applies the same safelist idea to agent tools, but it sends query text, not registered IDs, so test its tools after you turn on blocking. Read the persisted operations docs.
How do LLMs interact with GraphQL APIs?
An LLM agent can either introspect a GraphQL schema and write its own queries, or call operations a developer defined for it as tools, for example over the Model Context Protocol (MCP). The schema is typed and introspectable, so where introspection is enabled, the agent can see every type and field it can request. Predefined operations are the safer pattern, because the agent can only run what you approved. WunderGraph Cosmo works this way: the Cosmo MCP Gateway turns GraphQL operations into MCP tools that AI clients call, and each tool call can resolve data across the whole federated graph. Read why GraphQL works as the API layer for AI agents.
How do GraphQL subscriptions scale?
GraphQL subscriptions keep a long-running connection open for each client, over WebSockets, Server-Sent Events (SSE), or multipart HTTP. When the GraphQL server runs on several instances, events have to be shared across all of them so each client gets updates whichever instance it's connected to, for example through a pub/sub system such as Redis or NATS. Cosmo Streams applies this to federated GraphQL. Cosmo Router connects straight to Kafka, NATS/JetStream, or Redis and holds every subscriber connection, so subgraphs stay stateless and HTTP-only. The router also filters events per subscriber, with the @openfed__subscriptionFilter directive or a custom module. Learn more about Cosmo Streams.
Why do GraphQL subscriptions fail?
GraphQL subscriptions can fail at the protocol, the connection, or the event path. GraphQL never standardized a transport for subscriptions, so clients and servers can speak different protocols. Protocols also differ in how, or whether, they send heartbeats, which check that a connection is still alive. And when a GraphQL server runs on several instances, events must be shared across all of them, or a client misses events published on an instance it isn't connected to. Cosmo Router supports five subscription protocols for clients, and clients pick one when they connect. Each subgraph's protocol (WebSockets, SSE, or SSE over POST) is set when it's registered or updated, so the two don't have to match. With Cosmo Streams, services publish events to Kafka, NATS, or Redis and Cosmo Router serves the subscriptions, so subgraphs hold no subscriber state. Cosmo Router closes active subscriptions when it loads a new config, so clients should reconnect on disconnect. Read about the quirks of GraphQL subscription protocols.
How should teams review and approve GraphQL schema changes across services?
Route each change through a proposal that the owners of every affected part must approve, with automated checks against real client traffic. In WunderGraph Hub, you can't edit main directly: changes made in Hub go through a proposal on a branch. Hub validates each change as it's edited. When a proposal contains a breaking change, the Cosmo client-traffic check tests it against operations clients actually sent, so reviewers see what would break before it's published. Once owners are assigned, each affected owner becomes a required reviewer. Type owners review changes to their types regardless of which subgraph resolves them, and subgraph owners review changes that assign, remove, or modify fields in their subgraph. One change can need both. There's no partial approval, and open discussion threads block approval. Hub proposals require the graph to be connected to the Cosmo schema registry, with proposals enabled in Cosmo. Read the Hub governance docs.
How do I stop a GraphQL field deletion while clients still use it?
Run schema checks that test each change against real client traffic. In Cosmo, the operations check (client traffic in Hub) fails a breaking change, such as deleting a field, while clients still use that field within the lookback window: 7 days by default, configurable per namespace up to your plan's limit. It needs routers sending schema usage data, which they do by default. In WunderGraph Hub, a failing check blocks the proposal from approval. A failing check doesn't block a publish on its own. To gate it, make wgc subgraph check a required CI step before you publish. On pull requests with the Cosmo GitHub integration installed, wgc reports the result as a commit status instead of failing the step, so make that status check required instead. Or enable Cosmo proposals with Publish Severity set to Error so wgc subgraph publish rejects a schema that doesn't match an approved proposal. Separately, the Cosmo graph pruning rule REQUIRE_DEPRECATION_BEFORE_DELETION flags a field deleted without being deprecated first. Graph pruning is off until you enable it for a namespace, and each rule is turned on separately. The manual override in Cosmo Studio, for forcing a breaking change through, needs the GitHub integration. Read the schema checks docs.
Get started with Cosmo
Cosmo is open source, free to start, and available self-hosted or managed.
Published August 12, 2026 · Updated October 21, 2026 · WunderGraph
