Certified Group Services

Certified operates several CGS instances across production, staging, and test environments. This page explains what each one is for and which you should use in which scenario.

CGS is also self-hostable per operator — you don't have to use a Certified-operated instance. Anyone can run their own CGS against any AT Protocol PDS. The GROUP_PDS_URL setting configures where newly registered groups get their accounts; imported groups keep whatever PDS already hosts them, so one instance can span multiple PDSs (see Group lifecycle). The guidance below applies when you specifically want to use a Certified-hosted group service (for example, the "create a group" flow on certified.app).

Quick reference

¹ The version endpoints don't report on this instance yet; they will after its next upgrade.

Production: groups.certified.app

groups.certified.app is the production CGS. It's the instance that production applications should point at when they want group-governed repositories with role-based access control.

By the nature of AT Protocol's decentralized approach, CGS is not a requirement for apps built on Hypercerts — it's the production group service to use when you specifically want co-governed repositories.

Staging: dev.groups.certified.app

dev.groups.certified.app is a staging CGS. It's the final testing ground for CGS changes before they are promoted to the production instance at groups.certified.app.

• Any changes to dev.groups.certified.app are announced ahead of time.
• It can generally be treated as a fairly stable service.
• However, by design it is not guaranteed to be as stable as production.

Recommendation: most developers building apps that use group governance should point their staging environments at dev.groups.certified.app. It gives you an environment that closely tracks what will soon be in production, without exposing your users to an instance that may change without warning.

Test: test.groups.certified.app

test.groups.certified.app is strictly for use in testing. It runs the latest bleeding-edge CGS code and is not suitable for production or even staging workloads.

It's mainly used by the Hypercerts core development team. However, because development happens in public, anyone else who wants to run against the latest bleeding-edge code is welcome to test on it as well — as long as you understand the risks of doing so (data may be wiped, services may be unavailable, breaking changes may ship without notice, etc.).

Checking the running version

Like the ePDS, CGS exposes its version on two health endpoints:

/health — returns the CGS version as JSON, for example:

{"status":"ok","service":"group-service","version":"<semver>+<commit>"}

/xrpc/_health — returns the same payload. Unlike a plain AT Protocol PDS — where /xrpc/_health reports the upstream PDS version — CGS is its own service and is not a PDS, so both endpoints report the CGS version (service: group-service), not the version of the backing PDS it proxies to. To check the backing PDS version, query that PDS's own /xrpc/_health directly.

The test and staging instances (test.groups.certified.app and dev.groups.certified.app) report the version today. The production instance doesn't expose the version endpoints yet; it will after its next upgrade.

Status pages

CGS instances are tracked on the same Instatus pages as the rest of the Certified-operated infrastructure:

Which one should I use?

Related pages

• Certified Group Service (CGS) — how CGS works
• Certified PDSs — the PDS instances CGS proxies to
• Certified Services