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).
Groups registered through a hosted CGS are created on the PDS configured for that CGS deployment. The backing PDS is environment-specific: production, staging, and test CGS instances can point to their corresponding PDS environments. Imported groups remain on whichever PDS already hosts the account. See Certified PDSs for the current environment mapping.
Quick reference#
| Service | Environment | Who it's for | CGS version |
|---|---|---|---|
groups.certified.app | Production CGS | Production group-governed repositories | see /health |
dev.groups.certified.app | Staging CGS | Staging group governance for apps under development | see /health |
test.groups.certified.app | Test CGS | Hypercerts core development; bleeding-edge testing | see /health |
Service DID and proxy target#
Each hosted CGS instance publishes its service DID document at:
https://<cgs-host>/.well-known/did.json
The service DID is normally:
did:web:<cgs-host>
The current hosted integration calls CGS directly. If using optional AT Protocol service proxying, target the service with:
atproto-proxy: did:web:<cgs-host>#certified_group_service
Proxied group-scoped requests must also include repo, containing the group DID or handle.
The older did:plc:<groupDid>#certified_group target is deprecated and retained only for migration. See Certified Group Service for the request flows and the distinction between direct calls and service proxying.
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.appare 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.
All three instances — production (groups.certified.app), staging (dev.groups.certified.app), and test (test.groups.certified.app) — report the version on these endpoints.
Status pages#
CGS instances are tracked on the same Instatus pages as the rest of the Certified-operated infrastructure:
| Page | Covers |
|---|---|
certified.instatus.com | Production and staging services |
test-certified.instatus.com | Test services |
Which one should I use?#
| Scenario | Use |
|---|---|
| Production group-governed repositories in your app | groups.certified.app |
| Staging group governance in your app | dev.groups.certified.app |
| Contributing to Hypercerts core / testing bleeding-edge CGS changes | test.groups.certified.app |
Related pages#
- Certified Group Service (CGS) — how CGS works
- Certified PDSs — the PDS instances CGS proxies to
- Certified Services