Ship GraphQL schema changes
with confidence.

Nitro tests a proposed schema against the operations your clients publish to the target environment. See which operations and client versions a change could break, then fix it before users feel it.

Start Nitro for FreeRead client registry docs
schema.graphql
@@ type Order @@
4141 type Order {
4242 id: ID!
43+ totalAmount: Money!
43- total: Float!
RRegistryBREAKINGline 43

Removing Order.total breaks queries that still select it. Queries and mutations from 3 client versions published to this stage are affected. Deprecate it, then remove it after those versions are retired or unpublished from the stage.

4444 status: OrderStatus!
45+ placedAt: DateTime @deprecated(reason: "use createdAt")
4546 }
registry check failed1 breaking · 1 dangerous · 1 safe

Block breaking schema changes at the pull request.

Nitro returns a failed check when a proposed schema would break an operation published by a client. Configure that check as required in your repository, and the pull request cannot merge until the schema passes.

#482 · Add Money type
FAILRegistry check1 breaking · 2 safe
Schema validation: breaking changeOrder.total removed
Schema validation: additiveMoney, totalAmount added
Client compatibility: partner appvalidating...
Required CI policy blocks merge until checks pass.Re-run check

See which clients a change would break.

Validation runs against the operations your client versions have published to that environment. Each client gets its own result: a change can be safe for web and still break mobile, and you see that before you merge.

client registry·impact of #482
clientoperations passingstatus
web
production
5/5
OK
mobile
production
3/5
at risk
partner
sandbox
none published
outside result
internal-admin
staging
6/6
OK

Every environment is its own gate.

Development, staging, and production can each hold a different set of published operations. Validate against the environment you plan to update, because a change that passes staging may still affect client versions published to production.

Development
Passed
Staging
Failed
Production

Run the checks in the CI you already have.

The validate, upload, and publish steps ship as ready-made GitHub Actions and Azure Pipelines tasks, both wrapping the Nitro CLI.

GitHub Actions

.github/workflows/ci.yml
- uses: ChilliCream/nitro-schema-validate@v16 with: api-id: ${{ vars.NITRO_API_ID }} api-key: ${{ secrets.NITRO_API_KEY }} schema-file: ./schema.graphql stage: production comment-mode: review
✓ check passedGitHub Marketplace

Azure Pipelines

azure-pipelines.yml
- task: NitroSchemaValidate@16 inputs: authenticationType: serviceConnection nitroServiceConnection: nitro-prod apiId: $(NITRO_API_ID) schemaFile: ./schema.graphql stage: production
✓ task succeededVisual Studio Marketplace

Any other CI

shell
$ nitro schema validate \ --api-id $NITRO_API_ID \ --schema-file schema.graphql \ --stage production validating against production… ✓ no breaking changes
✓ exit 0CLI reference

Keep the full history of your schema.

Every uploaded or published schema leaves a browsable version in the registry, so your team can see what changed, how Nitro classified it, and which published clients the change could affect. See when a field changed without digging through merge commits.

schema history
  1. v12add Cart.discountSAFE
  2. v13deprecate Order.placedAtDANGEROUS
  3. v14remove Order.total (blocked)BREAKING
  4. v14add Order.totalAmountSAFE
  5. v15remove Order.total (no published client selects it)BREAKING

Know what breaks before your users do.

Publish the operations each client uses, validate proposed schemas against the environment you plan to update, and merge with the answer in hand.

Start Nitro for FreeRead Client Registry Docs