GraphQL Hive, an open source schema registry and observability platform for GraphQL, ready to publish, validate and monitor your schemas the moment it boots.
GraphQL Hive is an open source schema registry and observability platform for GraphQL APIs, and a self hostable alternative to hosted registries. It stores every version of your GraphQL schema, checks proposed changes for breaking changes before they ship, and composes federated or stitched schemas from many services into one supergraph. Teams publish schemas from CI with a small command line client, gate merges on schema checks, and browse the full history, composition results and usage of every type and field through a web console. Because it also ingests usage data from your gateway, it can show which fields are actually queried, flag unused parts of the graph, and make breaking change checks smarter by warning only when a change touches something clients really use.
It suits any team running GraphQL, from a single API to a federation of many services, that wants a registry, breaking change detection and usage insight on infrastructure they control rather than a third party service. The console, the registry API and the composition and usage services are all included so the platform is ready to use as soon as the instance is running.
cloudimg delivers the whole GraphQL Hive stack, the web console, the registry and authentication server, the schema, policy, token, workflow and usage services and their datastores, PostgreSQL, ClickHouse, Redis, a Kafka compatible broker and an object store, installed and wired together so the console answers the moment the instance boots, with no compose files to assemble by hand. The image is secure by default: the upstream project ships example passwords and signing keys for its datastores and sessions, and cloudimg bakes none of them. On the first boot of every instance a fresh set of database, cache, object store, encryption and session secrets is generated, a single owner account is created with a unique password, and the credentials are written to a root only file, so no two instances share a login and no upstream default ever governs a running console. The datastores are bound to the instance only and never exposed, the registry data lives on a dedicated data volume captured into the image, the base is fully patched with unattended security upgrades enabled, and every deployment is paired with a step by step deploy guide and backed by 24/7 cloudimg support.
Real screenshots taken while testing this image against its deployment guide.