Bluesky opens federation: accounts can live on PDS hosts outside Bluesky
What changed
On February 22, 2024 the AT Protocol team released early-access federation: anyone can run a PDS (Personal Data Server) and have its accounts join the network through Bluesky's relay. At launch each new PDS could host 10 accounts and was limited to 1,500 events per hour and 10,000 per day, and admins had to register through a Discord server. A May 2024 update on the same post removed the Discord registration step. Migration off the Bluesky PDS was possible but one way, and not recommended for main accounts.
What it means
Bluesky accounts can now be hosted on independent servers, so tools that post must find each account's own host instead of assuming bsky.social.
Who is affected
Scheduling and posting tools that log in to Bluesky accounts, and developers or organisations that want to host their own accounts.
What to do by 22 Feb 2024
Resolve each handle or DID to its PDS and send requests there, and test login and posting with an account on a non-Bluesky PDS.
What this means for you
Until February 2024 every Bluesky account lived on Bluesky's own servers. Now people and companies can keep their account on a server they run themselves, and it still works on Bluesky. If an app posts for you, it has to know where your account lives. Most apps already handle this, but a self-hosted account is the place where a badly built app can fail.
The details
- What shipped: an early-access PDS distribution with an installer (
bluesky-social/pds). Data from a connected PDS is routed through Bluesky's relay to feed generators and the Bluesky AppView. - Launch limits per new PDS: "each PDS will be able to host 10 accounts and limited to 1500 evts/hr and 10,000 evts/day." Past those limits the relay stops crawling the PDS until the period resets. Current relay limits are on the rate limits page; see also Bluesky documents label limits and changes relay limits.
- Registration: at launch, admins joined the PDS Admins Discord to be added to the relay allowlist. The post's "Update May 2024" says this requirement was removed and PDS instances can connect directly.
- Compatibility: the team said it was "not making promises of backwards compatibility" for the PDS distribution in this early period, while supporting a migration path for each release.
- Migration: accounts could move off the Bluesky PDS, but not back. The post warns that migrations involve "possibly destructive identity operations."
- For posting tools: an account's PDS is listed in its DID document. Later guidance says clients should not hardcode
bsky.social; see Bluesky deprecates hardcoding bsky.social.
What to do next
- Business owners: Nothing, unless you host your own Bluesky account; then check that your scheduling app can log in to it.
- Marketers and agencies: If a client uses a custom host, test posting from your tool before a campaign starts.
- Developers: Resolve handle to DID to PDS for every account, send API calls to that PDS, and keep a test account on a non-Bluesky PDS.
Primary sources
Get an email when a new API change is added
Follow new entries with the RSS feed. Each platform also has its own feed, for example X or Meta.