GoKawiilToday 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!
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.
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:
... continue reading