Bluesky Launches Protocol Services, Enhancing AT Protocol Infrastructure

Introducing Bluesky Protocol Services

A new home for the infrastructure Bluesky runs on the open network — including Jetstream v2 with network replay, a new Jetstream SDK, and a lex-based TypeScript SDK

August 13, 2026

By Alex Garnett

Today we’re launching Bluesky Protocol Services: a new brand, and a new website, for the public infrastructure Bluesky operates on the AT Protocol network.

Bluesky has always run more than the Bluesky app. We operate Jetstream instances, relays, and the Bluesky API endpoints built on atproto. But if you were a developer trying to build on that infrastructure, our docs didn’t always make it easy to tell what we run as a service or where to start. We’re fixing that today. Bluesky Protocol Services organizes all the documentation developers need within the ecosystem, clarifies the service contracts around Bluesky-provided infrastructure, replaces the old docs.bsky.app site and gives us a clean way to ship future releases like the ones in this post!

Jetstream v2: Network Replay

The headline release shipping alongside the new site is Jetstream v2. Jetstream is the best way for most developers to use the network at scale: you describe the slice you want, and it arrives as plain JSON over a WebSocket. What it couldn’t give you was history. If you needed the records that already existed on the network, you had to backfill repos yourself then cut over to the live stream.

Jetstream v2 adds that capability to the server. It keeps a compressed archive of the whole network and adds a new way to consume it, alongside the live tail:

Network Replay lets you catch up from any point in the past and cut over to live with no gap. You POST your filters to planSnapshot, download the sealed segments it returns over plain HTTP, then connect the live WebSocket once at the tip. Replay is stateless on the server, with no per-consumer cursor, no subscription to register, and nothing to stage on the client. Jetstream is your buffer. You can also just snapshot the network — a point-in-time copy of the archive over HTTP only (listSegments + getSegment), with no live tail. Same archive, same filters, no WebSocket.

This unlocks much more sophisticated server-side slicing without ever backfilling locally: you can spin up an App, run an analysis over a month of posts, or recover from downtime, all through the same JSON shape as the live tail.

Serving these archives is bandwidth-intensive. To ensure the service remains reliable and cheap to run, we’re now requiring an API token just for these requests. The live tail remains open and unauthenticated, it’s only when you request an archive that we require a token. We have no plans to introduce an auth requirement for the live stream.

The v2 instances are live now at wss://jetstream.us-west.bsky.network and wss://jetstream.us-east.bsky.network. The existing v1 instances will keep running unchanged for a while, and the live tail behaves identically on both, so there’s no rush to move. Read the full flow in the Network Replay docs.

And! As always, this infrastructure is open source and self-hostable. See Running your own Jetstream for details.

A Jetstream SDK

Jetstream is plain JSON, so you never need an SDK. But there’s some common glue: reconnecting, deduping, cursor management, decoding events into typed records. Hence, the new Jetstream SDKs: TypeScript and Go clients where you construct a Jetstream object, pass a filter, and for await over decoded, typed events:

import { Jetstream } from '@bsky/jetstream'
import { app } from '@bsky/sdk/lexicons'

const js = new Jetstream('https://jetstream.us-east.bsky.network')

for await (const evt of js.live({ collections: [app.bsky.feed.post] })) {
 if (evt.kind === 'commit' && evt.commit.operation === 'create') {
 console.log(evt.commit.collection, evt.commit.record.text)
 }
}

CopyCopied!

The TypeScript SDK is available from npm, including npmx.

The Go SDK is available as part of the Jetstream project.

The Jetstream SDK docs go into more detail.

The Bluesky TypeScript SDK, rebased on lex

Back in May we promoted the lex SDK to stable preview and promised that the standalone Bluesky docs would follow. That’s now done: the Bluesky TypeScript SDK is rebuilt on top of @atproto/lex, which means we’re no longer maintaining legacy code paths for Bluesky-specific helpers. This is the lexicon toolchain, fully typed end to end, from the protocol layer up through app.bsky records.

Every TypeScript example on this new site is written against it, marking a huge move away from legacy technical debt—this is good code hygiene for us, and should eliminate LLM recommendations for deprecated SDKs. If you’re still using @atproto/api code, it continues to work as before, and the Bluesky API guides serve as a migration reference.

Updates to endpoints.bsky.app

Finally, the HTTP reference has been updated. Spinning those docs out of https://docs.bsky.app was actually step 1 of this overhaul; we’re now landing the remainder.

The new network.bsky.jetstream.* methods that power Replay — planBackfill, listSegments, getSegment, and getBlock — are now browsable with full request and response schemas, and the reference now documents Jetstream’s WebSocket endpoints too, so the entire Jetstream v2 surface lives in one place.

What’s next

Everything above is live today: the new site, the v2 Jetstream instances, the SDK preview, and the updated HTTP reference. If you’re new to the network, start with How It Works, a visual walkthrough of how records, lexicons, and the firehose fit together. If you’re building against the Bluesky app’s data model, the Bluesky API guides are all still there, freshly rewritten (more on that below)

If you build something on Replay in the next few weeks, we’d love to hear about it; the fastest way to shape where the SDK’s orchestration goes is to show us what you’re folding the stream into.

Jetstream v2: Network Replay

A Jetstream SDK

The Bluesky TypeScript SDK, rebased on lex

Updates to endpoints.bsky.app

What’s next

Discussion

Discussion

1. jack@j4ck.xyz so cool!!

2. fry69@fry69.dev I think the link to the "new" docs site on the bottom of the post still points to the old docs? The newest blog post there is from January.

I think this is the new site? -> bsky.network

1. Jim Ray@jimray.bsky.team Quit reading so fast! Deploying a fix now, thanks for the heads up

2. surfdude29@surfdude29.ispost.ing is the image here final or a placeholder? I think it would look cool to use the Bluesky Protocol Services logo for the section header here, like you do for the Bluesky and AT Protocol sections :)

3. Dane@besaid.zone nice, gonna try this out after work

4. jack@j4ck.xyz btw this link seems to 404?

cool updates tho!! cc @alex.bsky.team

1. Jim Calabro ♟️@calabro.io fixed, thanks!
2. jack@j4ck.xyz np! :)
3. Dominik Picheta@dom96.picheta.me Awesome stuff, would love a blog post going into the technical details of how Jetstream v2 works.
4. Jim Calabro ♟️@calabro.io I'll write one some time soon! Didn't get it done in time for launch

read this in the meantime though, this gives the high-level

github.com/bluesky-soci... 06. John O Connell@corkiejp.wsocial.eu I think this deserves a repost on here as well. Applies equally to other clients #wsocial #eurosky etc. #atproto @denysvuika.wsocial.eu @anna.wsocial.eu

I like the convenience of my EXT 'AT Protocol Handler' post open in one client and easily reopened in another without copying and editing urls.

7. Evelyn@kandake.africa Fuck yeah been looking forward to this

8. Jim Ray@jimray.bsky.team Heroic docs work from @alex.bsky.team here.

And the new Jetstream from @calabro.io, @divy.zone and team is going to be a huge unlock for so many developers. Backfilling is easier than ever!

9. penny@hexmani.ac Liquid Glass accessibility violation influence is CRAZY

10. cyber professional@permadeath.com cool as hell

but it's also a bit odd to introduce this new branding and then have it link to... @bsky.app , esp since there's already other accounts like @safety.bsky.app or @support.bsky.team !

11. daniel holmgren 🫠@dholms.at huuuggee

kudos to everyone that worked on this. do yourself a favor & checkout jetstream v2

"v2" doesn't do justice to just how badass it is

12. Bill Dybas@billdybas.bsky.social Very excited about this

13. Jean-Marc Liotier@liotier.bsky.social Very handy.

14. Barry Dorrans@blowdart.me lol I still can’t jetstream v1 to work

15. Jacky!@omg.jacky.wtf more like v^2

16. Emily Hunt@emily.space This is awesome! @marshal.dev any thoughts on adding Jetstream support to the Python SDK?

I hacked something together a few months ago based on an example, it's pretty straightforward to subscribe to:

A method for the backfill stuff too would also be awesome!

17. Nick Gerakines@ngerakines.me This is good.

18. Luna@shi.gg huge!

19. Jacob@ebey.dev Yoooo

20. Wamellow@wamellow.com I wonder how much traffic a month selfhosting a jetstream with a single consumer would use (app.bsky only)

21. fig (aka:phil)@bad-example.com aw yea

22. gabboman the wafrn dev@gabboman.xyz jetstream v2? oh no will i have to update my code

23. Wade Minter@wademinter.com I just moved the Canes custom feed to Jetstream v2, easy as pie.

24. Samuel@samuel.fm so much exciting stuff here but big shout out to @divy.zone for @bsky/sdk, our shiny new TypeScript SDK! it's a thin layer of Bluesky-specific utils (like RichText) on top of the lexicon-agnostic Lex. modern, sleek, tree-shakable, all the good stuff. definitely check it out!!

25. Jerry Chen@jcsalterego.bsky.social jetstream

jetstream 2

jetstream 3: ntp drift

jetstream 4: 4 stream 4 furious

jetstream 5: the fate of the stream

jetstream 6: hobbs & shaw

1. Gears@gearsco.de Not jetstream 2 electric boogaloo?

2. stunwin@stunwin.com 2jet2stream

3. Technology Brobdingnagian@dfeldman.org strejeta7m: this one’s buggy

4. Jerry Chen@jcsalterego.bsky.social i knew UDP was a mistake

5. Keith Kurson@keithlaugh.love soooooo good, congrats on getting this out!

6. JP@byjp.me 😎

/cc @npmx.dev

1. npmx@npmx.dev ☺️

2. Tyler Fisher@tylerjfisher.com excited to tell youngins how i did backfill by hand and it took weeks, uphill both ways

3. Lyna@blooym.dev Does Bluesky still plan on keeping Tap in active maintenance / development with Jetstream now having its own backfill system? I prefer the DX of using it, but if it's going to be put to the side in favour of Jetstream, I'll probably have to switch to something else

4. Lyna@blooym.dev Running my own Jetstream seems like something I could do, but I'm not sure what that would be like compared to Tap with regards to storage usage when I only need to fill a small slice of the network (like my own apps records, nothing else)

5. Lyna@blooym.dev github.com/bluesky-soci... has a section header for "This is the next evolution of Jetstream v1? What happens to existing Jetstream v1? How does Tap play in to this?" which seems to indicate Tap is going to stick around and can actually work on-top of this seemingly, which is interesting

6. surfdude29@surfdude29.ispost.ing reply from @alex.bsky.team about Tap here 👀

7. Lyna@blooym.dev Hopefully the work on Tap after this doesn't cause a bunch of breaking changes since I've only just finalised my ingest code for my app and it would definitely contribute to some burnout if I've suddenly got to write/rewrite a whole new library for interacting with things again

8. Daniel McLaughlin@thedenial.bsky.social now only if the app wasn't so sluggish :S

9. Frank Hecker@frankhecker.com As @ricardo.bsky.social might put it, the infrastructure behind the Bluesky app is becoming more like a product (as opposed to a project). A natural evolution would be to charge Atmosphere app developers who piggyback on it and would like to have standard commercial SLAs and technical support.

10. Omasiri@uomasiri.bsky.social Network replay is a serious debugging primitive for protocol teams. The question I would ask next is how easy it is to replay only the slice where a client, relay, or moderation service went sideways.

11. Mike Masnick@masnick.com Big big news in the Atmosphere world.

12. Eli Mallon@iame.li Launching this when I’m with my family in north Minnesota is Not! Allowed!!!!

13. Ryan J. Gallagher@ryanjgallag.com I've been planning a new project that makes it easier for researchers to collect, store, and query Atmosphere data, and this Jetstream v2 update is a game changer

14. T.W. Simpson@simpsontw.bsky.social This obsoletes TAP?

15. Johannes Ernst@j12t.org Ah, finally! Bluesky has two main products: 1) managing the infrastructure and the customers are developers. 2) running an app, and the customers are individuals, businesses etc who post and like and reply etc. (And maybe other apps like Attie) Nice Bluesky is now clearly communicating this.

16. Johannes Ernst@j12t.org Of course, the same company producing both a platform and applications causes other problems. Similarly to how Microsoft has both an operating system, and applications, and the problems that happened there. Developers may be wary to build apps on the infrastructure of somebody who also builds apps.

17. Johannes Ernst@j12t.org It's already been happening with feed builders. Is that something Bluesky wants to compete in with Attie etc or look for the community to build? (like Graze). Where is the line where it is safe for app developers?

18. ATBrasil@atproto.com.br Para os desenvolvedores que utilizam pedaços da infraestrutura oferecida pelo Bluesky (Relay, Jetstream ou API, por exemplo), leiam este anúncio no blog para saber de algumas mudanças, como o lançamento do Jetstream v2, novo SDK pro Jetstream, e um novo site reunindo documentação da infraestrutura.

19. dan@danabra.mov ok i'm really glad this explanation exists bsky.network/docs/how-it-...

kind of wish atproto website had this instead though

40. dan@danabra.mov unexpected and cool