Bluesky Protocol Services: cheap AT Protocol access
Bluesky Protocol Services makes historical AT Protocol data a plain HTTP download instead of a server you have to keep alive. Why that matters on a small budget.
Bluesky Protocol Services is the new brand and website Bluesky has put around the public infrastructure it runs on the AT Protocol network, announced in Introducing Bluesky Protocol Services on the atproto.com blog. The headline feature is Network Replay in Jetstream v2.
The naming is not the interesting part. The interesting part is that getting historical network data stopped being a server you have to keep alive, and became a file you download. If you are building on a $5 VPS or a laptop, that is the whole story.
🔍 What actually changed
Jetstream is the service where, in Bluesky's words, "you describe the slice you want, and it arrives as plain JSON over a WebSocket." That part is old. What is new is that you are no longer stuck at the live edge.
Network Replay "lets you catch up from any point in the past and cut over to live with no gap." Mechanically:
POSTyour filters toplanSnapshot.- Download the sealed segments it returns over plain HTTP.
- Connect the live WebSocket once, at the tip.
There is also a snapshot-only mode: a point-in-time copy of the archive over HTTP alone (listSegments + getSegment), with no live WebSocket at all.
Key takeaway: The expensive part of building on a firehose was never the code. It was owning a process that must never die, because dying meant losing your place. Replay is "stateless on the server, with no per-consumer cursor, no subscription to register, and nothing to stage on the client." Your crash-recovery story is now "run the request again."
💰 The free/paid line, drawn honestly
Bluesky drew a line, and stated which side is which:
| Access mode | Transport | Auth required? |
|---|---|---|
| Live tail (current events) | WebSocket | No — "open and unauthenticated" |
| Archive / Network Replay | HTTP + WebSocket cutover | Yes — API token |
| Snapshot only | HTTP (listSegments + getSegment) |
Yes — API token |
Tokens come from bsky.network/account. On the live stream, the post is explicit: "We have no plans to introduce an auth requirement for the live stream."
No prices were published. The announcement introduces a token requirement for archive requests. It does not state a fee, a quota, or a rate limit. Anyone telling you what AT Protocol archive access costs right now is guessing. Read the terms on the account page before you design around it.
I would rather see a token requirement stated plainly than discover it as a silent throttle six months into a project. A token is also how you get told "you are being cut off" instead of just getting cut off.
⚡ Why this lands differently from Colombo
Run the old numbers for a student project that wanted three months of history from a social network:
| Cost item | Old way (self-backfill) | With Network Replay |
|---|---|---|
| Always-on process | Required — a dropped cursor meant re-doing work | Not required |
| Local storage of the full stream | Usually yes, then filter | Filter server-side, download the slice |
| Restart after a power cut | Painful; resume logic is yours to write | Re-issue the request |
| Client-side state to manage | Cursors, staging, dedupe | "nothing to stage on the client" |
That second column is a real bill in Sri Lanka. A VPS with enough RAM to hold a stream consumer plus a database is not a rounding error on a student budget, and an always-on process is a bad bet against a power interruption or an ISP reset. Statelessness converts an uptime problem into a bandwidth problem, and bandwidth you can buy in one burst at 2am.
One thing to check before you commit: the two live instances listed are wss://jetstream.us-west.bsky.network and wss://jetstream.us-east.bsky.network. No Asia-region instance is listed. For bulk HTTP segment downloads that barely matters. For a latency-sensitive live consumer, budget for a trans-Pacific round trip, or put the consumer on a cheap VM near one of those regions and pull results home.
🛠️ The SDK situation
Two client-side pieces shipped alongside:
- Jetstream SDK — TypeScript and Go clients "where you construct a Jetstream object, pass a filter, and
for awaitover decoded, typed events." Published as@bsky/jetstream. - Bluesky TypeScript SDK — rebuilt on top of
@atproto/lex, with end-to-end typing. Published as@bsky/sdk.
Plus reference material: the HTTP reference at endpoints.bsky.app now covers the new network.bsky.jetstream.* methods, and there are public cookbook and deploy-recipes repositories on GitHub.
A for await loop over typed events is roughly the lowest-friction shape this could take in TypeScript. If you have taught yourself async iterators, you already know the API. If you have not, this is a good excuse — it is one of the few JavaScript features that pays for itself immediately.
Since Jetstream hands you plain JSON, keep something around for eyeballing a single event before you write a parser against it. Our JSON formatter runs in the browser and is fine for that; paste one record, read the shape, then write the type.
💡 What this means for you
If you are a student, a freelancer, or a two-person team here, the practical read:
- Portfolio projects just got cheaper. A social-graph analysis, a Sinhala-language content classifier, a niche feed — all of these needed a backfill you could not afford. Now the historical part is a download.
- Prototype against the free live tail first. It is unauthenticated and Bluesky says it will stay that way. Only reach for a token when you actually need history.
- Do not design a product around unpriced infrastructure. Archive access is gated by a token with no published cost. Treat it as "free until told otherwise" and keep your data layer swappable.
- Read the filter model carefully. Filtering server-side is where the savings are. Downloading everything and filtering locally throws away the entire advantage.
- Measure from where you are. Test from a Sri Lankan connection, not from a US-based CI runner, before you promise anyone a latency number.
The wider pattern is worth naming: open protocols usually die at the data-gravity step, where the spec is free but the only usable copy of the network sits behind someone's expensive infrastructure. Making a stateless HTTP download the front door is the correct move, and it is the part I would watch. If the token stays cheap or free for small consumers, AT Protocol becomes a genuinely reasonable place to build from a country where nobody is expensing a data pipeline.
Facts in this post come from Bluesky's announcement on atproto.com. Where the source is silent — pricing, quotas, regional expansion — I have said so rather than filled the gap.
Original source
Bluesky Protocol Services