A single-user AT Protocol Personal Data Server (PDS) that runs on a Cloudflare Worker.
A PDS is where Bluesky data lives – posts, follows, profile, and media. Running a personal PDS provides:
- Independence from platform changes – If Bluesky's ownership or policies change, the account remains under full control. No billionaire can take it away.
- Network resilience – A diverse ecosystem of PDS providers makes the AT Protocol network stronger. More independent servers mean no single point of failure.
- Data sovereignty – The repository lives on infrastructure under direct control
- Portability – Move between hosting providers without losing followers or identity
This implementation uses Cloudflare Workers with Durable Objects and R2:
- Worker – Stateless edge handler for routing, authentication, and DID document serving
- Durable Object – Single-instance SQLite storage for your AT Protocol repository
- R2 – Object storage for blobs (images, videos)
The result is a PDS that runs at the edge with no servers to manage, automatic scaling, and pay-per-use pricing.
npm create pdsThis scaffolds a new project, installs dependencies, and runs the setup wizard. See the PDS package documentation for detailed setup and configuration.
| Package | Description |
|---|---|
@getcirrus/pds |
The PDS implementation – handles repository operations, federation, OAuth, and the CLI |
@getcirrus/oauth-provider |
OAuth 2.1 provider for "Login with Bluesky" |
create-pds |
Scaffolding CLI to create new PDS projects |
This is beta software under active development, but the core features are functional:
- Repository operations (create, read, update, delete records)
- Federation (sync, firehose, blob storage)
- OAuth 2.1 provider (PKCE, DPoP, PAR)
- Account migration from existing PDS
See the PDS documentation for current limitations and roadmap.
Your signing key controls your identity. Cloudflare secrets cannot be retrieved after they're set, so backing up your key during setup is critical.
When you run pds init, you'll be prompted to back up your signing key. Store it somewhere safe – a password manager, encrypted backup, or similar.
If you've cloned to a new machine and see the "Key Recovery Required" error:
- Restore from backup – If you backed up your key (recommended), add it to
.dev.vars:SIGNING_KEY=your-backed-up-key-here - Run init again –
pds initwill detect the local key and continue
For did:web users:
- Generate a new key by clearing
.dev.varsand re-runningpds init - Old signatures become unverifiable – followers may see warnings
- Your identity continues, but there's no cryptographic proof of continuity
For did:plc users:
- If you have a recovery key registered with PLC, you can rotate to a new signing key
- Without a recovery key, you'll need to start a new identity
- See the AT Protocol PLC documentation for recovery operations
- Cloudflare account with R2 enabled
- A domain you control (for your handle and DID)
MIT. © Matt Kane (@ascorbic)