Today we’re launchingBluesky Protocol Services: a new brand, and a new website, for the public infrastructure Bluesky operates on theAT Protocolnetwork.
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 isJetstream 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 washistory. 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 Replaylets you catch up from any point in the past and cut over to live with no gap. YouPOSTyour filters toplanSnapshot, download the sealed segments it returns over plain HTTP, then connect the live WebSocket once at the tip. Replay isstateless 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 alsojustsnapshot 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 anApp, 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 anAPI 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 atwss://jetstream.us-west.bsky.networkandwss://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 theNetwork Replay docs.
And! As always, this infrastructure is open source and self-hostable. SeeRunning your own Jetstreamfor details.
Jetstream is plain JSON, so you neverneedan SDK. But there’s some common glue: reconnecting, deduping, cursor management, decoding events into typed records. Hence, the newJetstream SDKs: TypeScript and Go clients where you construct aJetstreamobject, pass a filter, andfor awaitover decoded, typed events:
The TypeScript SDK is available from npm, includingnpmx.
The Go SDK is available as part of theJetstream project.