The Bluesky PDS on AWS by FOSSonCloud pattern now ships PDS v0.4.5009, up from v0.4.219.
That’s the widest-looking version jump of any pattern this cycle, and the number is misleading. Bluesky’s PDS ships frequent rolling builds without individual public changelogs for each increment, so build “5009” doesn’t map to a single discrete release the way semantic versioning does elsewhere. Rather than invent specifics we can’t verify, here’s what’s accurate about this period of AT Protocol development.
What changed
- Continuous stability and federation hardening as the protocol matures — the PDS has moved through thousands of incremental builds.
- Bluesky enabled incoming account migration back to its own PDS. Previously, once you migrated your account away from
bsky.socialto a self-hosted or third-party PDS, you couldn’t return. That one-way restriction has been lifted. - OAuth support has continued to mature across the PDS, the TypeScript client SDK, and the broader ecosystem of independent client implementations.
Why it matters
The incoming migration change is the most consequential item here, and it isn’t a code change on your side at all — it’s a change in what self-hosting costs you if it doesn’t work out.
Before this, migrating your account off bsky.social was irreversible. That made self-hosting a serious commitment: if your instance turned out to be more operational work than you wanted, or you couldn’t keep it reliable, you were stuck maintaining it. That’s a real deterrent, and it kept a lot of people who were curious about running their own PDS from ever trying.
With incoming migration enabled, self-hosting becomes something you can try. Migrate out, run your own PDS, and if it isn’t for you, migrate back. For anyone evaluating whether to run their own infrastructure on AT Protocol, that changes the risk calculation more than any individual feature would.
Maturing OAuth support is the quieter but structurally important development. OAuth across the PDS, the official TypeScript SDK, and independent clients is what lets a diverse client ecosystem exist without every app asking users for app passwords. As that matures, the practical difference between “my account lives on bsky.social” and “my account lives on my own PDS” shrinks — third-party clients work the same either way.
What you should do
- Nothing urgent — no breaking changes have been flagged for this period. Treat this as a routine update.
- Keep the pattern current on a normal schedule. Because the PDS ships rolling builds rather than versioned releases with changelogs, “stay reasonably current” is a better policy than “wait for a release that looks important,” since you can’t tell from the version number.
- If you’ve been hesitant to migrate an account to your self-hosted PDS, the calculation has changed. Migration back to
bsky.socialis now possible, so trying self-hosting is no longer an irreversible decision. - Test your own migration path before you need it. Knowing that migration back works in principle is not the same as having confirmed it works for your setup — verify it while nothing is on fire.
- Review how your clients authenticate. As OAuth matures across the ecosystem, moving off app passwords where clients support it is the better long-term posture.
Because Bluesky’s PDS doesn’t publish per-build changelogs, this post deliberately describes the period rather than claiming specifics for a single build. If you hit anything upgrading the pattern, open an issue on GitHub.
— FOSSonCloud