GraphQL Hive

GraphQL Hive is a fully open-source schema registry and analytics platform built by The Guild for GraphQL APIs of all kinds — standalone, stitched, and federated. It gives development teams a single place to track schema evolution, prevent breaking changes before they reach production, and understand how their APIs are actually used in the wild.

At its core, Hive connects schema publishing in your CI/CD pipeline with live operation monitoring from production traffic. When a developer proposes a schema change, Hive cross-references it against real client queries to determine whether that change is truly breaking — not by static analysis alone, but by data-driven impact assessment based on what your actual users are sending.

The platform ships with a rich web console built on Next.js and React, a Hive CLI for CI integration, client libraries for GraphQL Yoga, Apollo, Envelop, and an Apollo Router plugin written in Rust for high-performance edge deployments. Hive runs either as a managed cloud service (including a generous free Hobby tier) or entirely self-hosted on your own infrastructure using the provided Docker Compose and Kubernetes configurations.

Under the hood, Hive is a multi-service system backed by PostgreSQL for schema and metadata, ClickHouse for high-throughput operations analytics, Redis for caching and pub/sub, and Cloudflare Workers for a globally distributed schema CDN. Every component is MIT-licensed and built in the open, making it a credible long-term alternative to proprietary offerings like Apollo GraphOS.

What You Get

• Schema Registry with Full History - Publish and version your GraphQL schemas across targets (development, staging, production) with a complete audit trail of every change, including composed schemas from Apollo Federation and schema stitching.
• Data-Driven Breaking Change Detection - Analyze proposed schema changes against real production operation data to determine which changes are truly breaking for your actual clients, not just theoretically incompatible.
• Schema Proposals & Review Workflow - Collaboratively propose, comment on, and approve schema changes through a structured review process before they are published, keeping teams aligned on API evolution.
• GraphQL Observability Dashboard - Monitor real-time API performance metrics including request per minute, latency percentiles, error rates, and active client counts segmented by operation and client version.
• CI/CD Integration via Hive CLI - Enforce schema checks in any CI system (GitHub Actions, BitBucket, Azure DevOps) to block deployments that introduce unsafe changes, with native GitHub PR status checks.
• Apollo Federation v1/v2 Support - Full compatibility with Apollo Federation specifications including subgraph composition, supergraph SDL generation, and real-time subscription support across subgraphs.
• Policy Engine for Schema Governance - Define and enforce custom schema linting rules to maintain consistency across teams, preventing anti-patterns and enforcing naming conventions at publish time.
• Persisted Documents / Trusted Documents - Register allowed GraphQL operations ahead of time to only permit known queries in production, improving security and enabling aggressive schema optimizations.
• Cloudflare CDN Schema Access - Serve your schema registry artifacts through Cloudflare’s global edge network for high-availability schema fetching with multi-zone redundancy and low latency worldwide.
• App Deployments Tracking - Track which version of your client applications are active in production, enabling precise impact analysis when checking schema changes against real clients.

Common Use Cases

• Replacing Apollo GraphOS - A team migrates from Apollo Studio to Hive Console to eliminate proprietary vendor lock-in while retaining schema registry, breaking change detection, and federation composition under MIT license.
• Governing a multi-team federated API - Multiple backend teams own independent subgraphs; Hive validates composition on every PR, blocks breaking changes from merging, and gives each team visibility into how their subgraph is consumed across the supergraph.
• Enforcing schema standards in a large org - A platform team writes custom policy rules to enforce naming conventions and deprecation practices, and Hive blocks schema publishes that violate those rules before they enter any environment.
• Monitoring GraphQL API health after migration - After migrating a REST API to GraphQL, an engineering team uses Hive’s operations analytics to identify slow resolvers, unused fields, and high-error-rate queries and systematically improve them.
• Securing production with persisted documents - A financial services company registers only pre-approved operations with Hive’s trusted documents feature, rejecting arbitrary queries in production to reduce the attack surface of their GraphQL API.
• Tracking client app rollouts - A mobile team uses Hive’s app deployment tracking to understand which client versions are still active in the wild, ensuring that schema changes won’t silently break users on older app versions.

Under The Hood

Architecture GraphQL Hive is organized as a Turborepo monorepo with clearly separated service packages: an API gateway built on GraphQL Modules and Fastify, dedicated microservices for schema composition, usage ingestion, CDN delivery, policy enforcement, and billing, plus a React/Next.js web console and a collection of client-side integration libraries. Services communicate internally via tRPC, keeping contracts type-safe across service boundaries without the overhead of a full GraphQL layer between services. The CDN worker runs on Cloudflare Workers at the edge, and an Apollo Router plugin is implemented in Rust for native high-performance integration with the Apollo Router. This separation lets each service scale and deploy independently while sharing common abstractions from the internal package layer.

Tech Stack The platform is built on TypeScript 5.7 with Node.js 24, using GraphQL Modules for the modular API server, Fastify as the HTTP layer, and GraphQL Yoga as the execution engine in client libraries. Schema storage and metadata live in PostgreSQL accessed via Slonik; high-throughput operations analytics are stored and queried in ClickHouse; Redis handles caching and pub/sub. The web frontend uses Next.js with React, Tailwind CSS, and Radix Primitives. Authentication runs on SuperTokens. Infrastructure is described as code with Pulumi targeting Azure, Kubernetes with Contour/Envoy, and Cloudflare for edge components. The Rust Apollo Router plugin uses the hive-console-sdk-rs crate. Build orchestration uses Turborepo and pnpm with comprehensive patch overrides for upstream dependencies.

Code Quality The codebase demonstrates extensive testing discipline with Vitest for unit and integration tests, Playwright for end-to-end browser tests, and a dedicated integration-tests directory that spins up realistic service interactions. TypeScript strict mode is enforced throughout with GraphQL Codegen generating type-safe resolver and client types. Error handling uses explicit typed error unions surfaced through GraphQL result types rather than thrown exceptions, providing predictable failure modes. The policy service and schema composition service have strong input validation via Zod. CI runs lint, type checks, and tests on every PR. Custom ESLint rules are codified in a local rules/ package, reflecting the team’s investment in codifying and automatically enforcing their conventions.

What Makes It Unique Hive’s most distinctive capability is coupling schema change analysis to live production operation data. Rather than flagging any removed field as a breaking change, Hive can tell you that a field you want to remove has received zero queries in the past 30 days and is therefore safe to remove without impacting any real client. This data-driven approach to breaking change detection is a meaningful departure from purely static analysis. The combination of a Cloudflare edge CDN for schema distribution, a Rust Apollo Router plugin for zero-overhead schema fetching, and a full Turborepo monorepo that ships both the cloud infrastructure and the self-hosted Docker Compose stack in a single MIT-licensed repository makes Hive one of the most complete open-source alternatives in the GraphQL tooling ecosystem.

Self-Hosting

GraphQL Hive is released under the MIT License, one of the most permissive open-source licenses available. This means you can use it commercially, modify it, distribute it, and include it in proprietary systems without any copyleft obligations. There are no source-available restrictions, no BSL conversion clauses, and no open-core licensing tricks — the entire codebase including the billing and commerce service is MIT-licensed and publicly available on GitHub.

Self-hosting Hive is a non-trivial operational undertaking. The platform requires PostgreSQL, ClickHouse (a columnar analytics database that can be resource-intensive), Redis, and optionally a Cloudflare Workers account for the CDN component. A Docker Compose configuration is provided for local and small-scale deployments, and Kubernetes manifests managed by Pulumi are used for production at scale. You are responsible for database provisioning, backups, upgrades, and scaling each service independently. The schema composition service includes a Rust build step, and the CDN worker targets Cloudflare’s edge runtime specifically, so self-hosters who want the edge CDN features need a Cloudflare account. The team provides a deployment changelog and detailed documentation, but expect to invest meaningful ops time to keep a self-hosted instance healthy.

The managed Hive Cloud offering hosted by The Guild adds several practical advantages: a generous free Hobby plan (1 million operations per month, 7-day retention), Pro and Enterprise tiers with higher retention windows and unlimited operations, dedicated support channels, SLA guarantees, and automatic infrastructure management. Self-hosters give up these support structures and must handle all operational concerns themselves, but gain complete data sovereignty and the ability to modify behavior for their specific needs. For teams with strong infrastructure capability and strict data residency requirements, self-hosting is fully viable; for everyone else, starting with Hive Cloud and migrating to self-hosted later is a reasonable path since the protocol and data model are identical.