Certified PDSs

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

Apps built on Hypercerts don't need to use a Certified PDS — any AT Protocol PDS will work. The guidance below applies when you specifically want to offer "Sign in with Certified" or otherwise integrate with the ePDS extension.

Quick reference

¹ Pre-0.2.0: includes the login-hint feature and initial handle picker from 0.2.0, but not configurable OTP, epds_handle_mode, email masking (0.2.1), or the consent screen fixes (0.2.2). Upgrade imminent.

² /xrpc/_health is not yet reporting the PDS version on this instance; version determined from pnpm-lock.yaml at the deployed commit.

Note the distinction between these ePDS backends and certified.app — the frontend app that end users interact with to manage their certified.one identity (and other AT Protocol identities). certified.app is not an ePDS; it's a client that talks to one.

Production: certified.one

certified.one is the production ePDS. It's the backend behind the Certified frontend at certified.app, and the endpoint that production applications should point at when they implement "Sign in with Certified".

By the nature of AT Protocol's decentralized approach to identity and data storage, any ATProto app can be used with any PDS — so certified.one is not a requirement for apps built on Hypercerts, just the production ePDS to use when you specifically want to offer Sign in with Certified (e.g. to get email/OTP login via the ePDS extension).

Staging: dev.certified.app

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

• Any changes to dev.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 offer "Sign in with Certified" should point their staging environments at dev.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. (Apps that don't use Certified for sign-in don't need to point at any Certified-operated ePDS — any ATProto PDS will do.)

Test instances: *.test.certified.app

Anything under the test.certified.app domain is strictly for use in testing. These instances run the latest bleeding-edge ePDS code and are not suitable for production or even staging workloads.

These instances are 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 them 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.).

Current test instances

Checking the running version

There are two version endpoints to be aware of:

ePDS version (/health) — ePDS instances that have been upgraded to the versioned release (ePDS PR #74 and later) expose a /health endpoint that returns the ePDS version as JSON, for example:

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

Older instances that pre-date this feature are marked as "old / unversioned" in the tables above. For what changed in each ePDS release, see the ePDS release notes on GitHub.

Underlying PDS version (/xrpc/_health) — every AT Protocol PDS (including ePDS instances) exposes /xrpc/_health, which returns the upstream PDS version:

{"version":"<version>"}

This is a standard AT Protocol endpoint and works on vanilla PDS instances out of the box. On ePDS instances, the version may currently be missing from the response due to a known bug (imminent fix); if you see an empty {} response, that's why.

Naming scheme

Hostnames under test.certified.app correspond to individual test ePDS instances. New instances may be spun up and old ones retired as the core team's testing needs evolve, so treat the list above as a point-in-time snapshot rather than a stable contract. If you need to run against a specific test instance, confirm with the Hypercerts core team that it is still active.

Auth services

Each ePDS is paired with an auth service (e.g. auth.certified.one, auth.dev.certified.app) that handles the email/OTP step of the ePDS flow. You don't talk to it directly — the PDS routes users through it during OAuth — but it shows up in status pages and logs alongside the PDS itself.

Status pages

Operational status for the Certified-operated ePDSs is tracked on two Instatus pages:

For non-PDS infrastructure (for example Hyperindexer/Hyperlabeller and ecosystem-facing links), see Certified Services.

Group-governed PDSs

If a single repository needs to be co-managed by multiple identities with different permission levels, the Certified Group Service (CGS) sits in front of a PDS and adds role-based access control on top. Certified operates a hosted CGS instance, and CGS can also be self-hosted; either way it can proxy to any AT Protocol PDS, including the Certified-operated PDSs above.

Which one should I use?