How to Test a PDS Setup Before Migrating a Real Bluesky Account

Migrating a Bluesky account to a self-hosted Personal Data Server (PDS) requires careful preparation. A single misconfiguration can cause downtime, data loss, or permanent account lockout. Testing the PDS setup with a dummy account prevents these risks. This article explains how to validate each component of your PDS before moving your real handle and data.

Key Takeaways: Validating Your PDS Before Bluesky Migration

Create a temporary test account on the PDS: Use the admin API or a test invite code to simulate a real user without affecting your main account.
Verify DNS and SSL certificates: Confirm that your domain resolves correctly and HTTPS is enforced before the migration window opens.
Run a full data export and import cycle: Use Bluesky’s export tool to back up your real account, then test restoring that data to the dummy account on the PDS.

Why Testing a PDS Before Migration Matters

A Bluesky PDS is a self-hosted server that stores your account data, posts, and cryptographic keys. When you migrate, your existing account data must be transferred to the new PDS and the domain handle must be re-pointed. If the PDS is misconfigured, the migration process can fail halfway, leaving your account in a broken state where neither the original server nor the new one can serve your data.

Common failure points include incorrect DNS records, missing SSL certificates, firewall blocks on required ports, and disk space exhaustion. Testing with a throwaway account catches these issues without risking your real followers or post history. The test also verifies that the PDS can handle the database size and request volume of your actual account.

What You Need Before Testing

You need a domain name that you control, a server with at least 2 GB of RAM and 20 GB of storage, and Docker installed. You also need the Bluesky PDS software configured according to the official documentation. For the test account, you can generate an invite code from the PDS admin panel or use the pdsadmin CLI tool to create a user directly.

Steps to Test a PDS Setup with a Dummy Account

Create a test user on the PDS
SSH into your PDS server. Run sudo pdsadmin account create and enter a temporary handle like testuser.yourdomain.com. The tool returns a password and a DID. Save both in a password manager. This user is fully isolated from your real account.
Verify DNS resolution for the test handle
Check that the test handle’s domain resolves to your PDS IP address. Use dig testuser.yourdomain.com from a machine outside your network. The response must show an A or AAAA record pointing to your server. If it returns a different IP, update your DNS zone file.
Confirm SSL certificate covers the test domain
Open https://testuser.yourdomain.com in a browser. The padlock icon must appear with no certificate warnings. If you use a wildcard certificate, ensure it covers yourdomain.com and all subdomains. If the certificate is missing, run sudo certbot --nginx -d yourdomain.com -d yourdomain.com.
Log into the test account via the official Bluesky app
Open the Bluesky app or web client. Click Settings > Advanced > Custom PDS. Enter your PDS domain (e.g., pds.yourdomain.com) and the test user’s handle and password. The app must load the timeline, profile, and settings without errors.
Perform a data export from your real account
Log into your real Bluesky account. Go to Settings > Privacy and Security > Export My Data. Download the ZIP file. This file contains your posts, likes, follows, and media. Store it in a secure location outside the PDS.
Import the exported data into the test account
On the PDS server, run sudo pdsadmin account import with the test user’s DID and the path to the ZIP file. Wait for the import to complete. Check the PDS logs with sudo journalctl -u pds for any errors. The import should finish within a few minutes for accounts under 100 MB.
Verify the imported data in the test account
Log into the test account again. Browse the timeline, check that your old posts appear, and confirm that follower counts match. If any data is missing, re-run the import after fixing the error shown in the logs.
Test handle resolution for the test domain
Use Bluesky’s public API to resolve the test handle: curl https://api.bsky.app/xrpc/com.atproto.identity.resolveHandle?handle=testuser.yourdomain.com. The response must return the test user’s DID. If it returns an error, your DNS or PDS configuration is incorrect.
Simulate a server restart and check persistence
Reboot the PDS server with sudo reboot. After the server comes back, log into the test account again. All posts, follows, and settings must be intact. If data is lost, check that your Docker volumes are mounted on persistent storage, not a temporary filesystem.
Delete the test account after validation
Run sudo pdsadmin account delete with the test user’s DID. This frees disk space and removes the test data. Keep the export ZIP file for the real migration.

Common Issues During PDS Testing and How to Fix Them

Test account cannot log in from the official app

If the app shows “Invalid handle or password,” verify that the Custom PDS URL in the app matches the PDS hostname exactly. Do not include https:// in the custom PDS field. Also confirm that port 443 is open on your server firewall. Run sudo ufw status to check.

Data import fails with “Disk full” error

The PDS stores data in Docker volumes located at /pds by default. Check disk usage with df -h. If the volume is full, resize the disk or move the volume to a larger partition. After freeing space, restart the PDS service with sudo systemctl restart pds and retry the import.

Handle resolution returns a different DID

This means your DNS has a stale or incorrect TXT record. Remove any old _atproto TXT records from your DNS zone. The PDS handles DID-to-handle mapping internally. Only the A or AAAA record is required. Wait for DNS propagation, which can take up to 24 hours.

Test Account vs Real Account: Comparison Table

Item	Test Account	Real Account
Handle	Temporary subdomain (e.g., test.yourdomain.com)	Your actual handle (e.g., yourname.bsky.social)
Data	Imported from real account for validation	Original live data with posts, follows, and media
Risk	None; can be deleted after testing	Permanent loss if migration fails
DNS changes	Only subdomain records modified	Root domain records must be updated
Invite code needed	Generated from PDS admin	Already has an account on existing PDS

Testing with a dummy account is the only safe way to confirm that your PDS can handle authentication, data import, and DNS resolution. Once every step passes, you can proceed with the real migration using the same export file and the same PDS configuration.

← Back to WiseChecker Home More in Windows & PC