Something went wrong. Try again.
Personal atproto services deployment handbook
Something went wrong. Try again.
Migration #
This document covers moving PDS compute from the current GCP VM to another VM or cloud provider while preserving account identity and data.
What Moves #
/pdsrestored from backup- Docker/PDS service configuration
- Caddy origin TLS configuration
- backup timer and environment
What Stays #
- live R2 blob bucket
- backup R2 bucket or prefix
- account DID
3drx.tophandle TXT record- Cloudflare zone
Migration Steps #
- Run a fresh backup on the source VM.
- Stop PDS on the source VM to avoid concurrent writes during final copy.
- Run one final backup.
- Restore that backup onto the destination VM.
- Install Docker, service files, Caddy config, and backup timer on the destination.
- Confirm the destination can reach R2 live blob and backup buckets.
- Update
pds.3drx.topDNS to the destination VM IP. - Run health checks and account login checks.
- Keep the old VM stopped but not deleted until the destination has run successfully for several days.
Provider Requirements #
The destination provider needs:
- public IPv4 or compatible Cloudflare origin routing
- inbound
80/tcpand443/tcpallowed - outbound HTTPS to Cloudflare/R2
- enough disk for
/pdsand temporary backup extraction - enough memory for Docker/PDS; use swap on very small VMs
Identity Notes #
Do not create a new account as part of migration. The restored /pds contains the existing account and DID state.
Do not change _atproto.3drx.top unless intentionally moving to a different DID.
Do not run two active PDS instances from the same restored state at the same time.