Personal atproto services deployment handbook
atstack docs migration.md
1.6 kB · 49 lines
Markdown
at main

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 #

  • /pds restored 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.top handle TXT record
  • Cloudflare zone

Migration Steps #

  1. Run a fresh backup on the source VM.
  2. Stop PDS on the source VM to avoid concurrent writes during final copy.
  3. Run one final backup.
  4. Restore that backup onto the destination VM.
  5. Install Docker, service files, Caddy config, and backup timer on the destination.
  6. Confirm the destination can reach R2 live blob and backup buckets.
  7. Update pds.3drx.top DNS to the destination VM IP.
  8. Run health checks and account login checks.
  9. 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/tcp and 443/tcp allowed
  • outbound HTTPS to Cloudflare/R2
  • enough disk for /pds and 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.