rsky: A Rust AT Protocol Stack With Postgres, S3 and Mailgun Underneath
An AT Protocol implementation prioritizing community safety and self-governance, written in Rust.
At a glance
- What is it?
- rsky is a work-in-progress AT Protocol implementation in Rust, split into reusable crates and a set of services including a PDS, relay, feed generator and labeler. Its PDS swaps the canonical TypeScript stack's SQLite and on-disk blobs for Postgres, S3-compatible storage and Mailgun, which changes who can realistically operate it.
- Who is it for?
- Adopt rsky if you are building AT Protocol tooling in Rust and can accept pre-1.0 churn, or if you want a PDS whose state lives in Postgres and S3-compatible storage rather than SQLite and local disk. Do not adopt it as a drop-in replacement for the canonical TypeScript implementation without reading each service's own README first.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What rsky Is Trying to Do That the Reference Implementation Does Not
The AT Protocol already has a reference implementation, written in TypeScript. rsky exists because a second implementation in a different language makes different deployment choices possible, and because the Blacksky community wanted services shaped around its own moderation and governance needs rather than the defaults of a general-purpose client. The README is direct about the split: most of the code is described as general purpose implementations, while some pieces, naming rsky-feedgen specifically, are tied to Blacksky's use cases.
The audience is therefore narrower than "anyone who wants a decentralized social network". It is Rust developers who need AT Protocol primitives, and operators willing to run a PDS or relay with infrastructure that is not the reference stack's. The repository carries a warning that until version 1.0.0 is reached, stability is not guaranteed, and that things will change, are incomplete, and will break. That warning is the single most important line in the README for anyone evaluating adoption.
Crates and Services: Two Layers With Different Stability Expectations
The repository is organized into two layers. The crate layer holds rsky-crypto for cryptographic signing and key serialization, rsky-identity for DID and handle resolution, rsky-lexicon for the schema definition language, rsky-syntax for string parsers for identifiers, rsky-common for shared code, and rsky-repo for the data storage structure including the MST. Each of these has its own README in its own directory and its own page on crates.io, which means they can be consumed independently of the services.
The service layer is where the operational weight sits. rsky-relay is described as handling big-world networking: it crawls the network, gathers as much data as it can, and outputs one stream for other services. rsky-pds hosts repository content for accounts. rsky-feedgen is a Bluesky feed generator. rsky-firehose and rsky-jetstream-subscriber consume the two stream formats. rsky-labeler consumes the firehose and labels content. rsky-satnav is described as a DASL CAR and AT Protocol repository explorer, and rsky-wintermute is an indexer for the bsky app-view.
That is a lot of surface area for a pre-1.0 project. The roadmap shows feedgen and firehose consumer, PDS implementation, and a frontend Bluesky client as done, with a feedgen admin client still unchecked. Nothing in the material indicates which services are actively deployed versus which are scaffolding.
The PDS Is the Interesting Design Decision
The README states plainly how rsky-pds differs from the canonical TypeScript implementation: Postgres instead of SQLite, S3-compatible blob storage instead of on-disk, and Mailgun for email. The stated reason is to make the PDS easier to migrate between cloud hosting providers and more maintainable.
That is a real trade-off, not a cosmetic one. SQLite and local disk make a PDS a single directory you can copy. Postgres and S3 make it a set of managed services you point at. The first is easier to stand up on a VPS and easier to back up by hand. The second is easier to move between providers, easier to scale horizontally, and easier to snapshot, but it introduces a database dependency, an object storage dependency, and a third-party email dependency into the critical path of a service that is supposed to be self-hosted. If Mailgun is down, email flows through the PDS are affected. The README does not describe a fallback.
The design also assumes you are comfortable running Postgres. For a community operator who wants a personal data server on a small box, that assumption is the main cost of choosing rsky over the reference PDS.
Getting It Running: What the Material Actually Specifies
The README does not include installation commands, a docker-compose file, environment variable names, or a quickstart. What it does give is the crate table, with each crate linking to its own README and its crates.io page, and a list of service names. The practical consequence is that setup instructions live per component, not at the repository root. To use rsky-crypto, rsky-identity, rsky-lexicon, rsky-syntax, rsky-common or rsky-repo, you would start from that crate's own README and its crates.io listing. To run rsky-pds, rsky-relay, rsky-feedgen, rsky-firehose, rsky-jetstream-subscriber, rsky-labeler, rsky-satnav or rsky-wintermute, you would start from the corresponding directory in the repository.
I cannot state the exact commands, config keys or environment variables, because they are not present in the material I have. Anyone writing a deployment guide for this project needs to read the individual crate and service READMEs first. The absence of a top-level quickstart is itself a signal about the project's current phase: it is a codebase for people who will read the source, not a product with a one-command install.
Where rsky Is the Wrong Tool
The stability warning is not boilerplate. A project that says things will break before 1.0.0 is telling you that the API surface of its crates and the configuration surface of its services can change without a deprecation cycle. If you are building something with a long support window, pinning to a specific commit and vendoring is the only sane posture, and that is a maintenance burden you are choosing.
The second limitation is scope mismatch. rsky-feedgen is explicitly tied to Blacksky's community use cases. If your feed generator needs behaviour that diverges from those use cases, you are adapting someone else's opinionated service rather than configuring a neutral one. The same applies to rsky-labeler: labelling policy is a governance decision, and the README does not describe how configurable that policy is.
The third is operational. The PDS's reliance on Postgres, S3-compatible storage and Mailgun means the set of people who can run it is smaller than the set who can run a SQLite-and-disk PDS. That is a deliberate trade for portability, but it is still a narrowing.
The Alternative, and the Actual Difference
The obvious alternative is the canonical TypeScript implementation from Bluesky PBC, which the README itself points to for protocol documentation and discussions. The difference is not language preference. It is that the reference implementation's PDS uses SQLite and on-disk blob storage, which means a single-host deployment with no external database or object store. rsky-pds uses Postgres and S3-compatible storage, which means a deployment that can be moved between cloud providers by repointing connection strings and bucket endpoints rather than copying a directory.
If your goal is the smallest possible footprint for a personal data server, the reference stack wins on that axis. If your goal is a PDS whose state is already in managed infrastructure, rsky-pds is aimed at you. Choosing between them is choosing which migration story you want to live with.
For the crate layer, the comparison is different. There is no equivalent set of standalone Rust crates for AT Protocol primitives from the reference project, because the reference project is TypeScript. If you are writing Rust and need DID resolution, lexicon handling or MST storage, rsky's crates are the direct option, and their crates.io presence means you can depend on them without vendoring the whole repository.
Maintenance, Licensing and What to Check Before You Commit
The repository is Apache-2.0. That is a permissive licence with an explicit patent grant, and it is compatible with commercial use. It is not a copyleft licence, so modifications you distribute do not have to be published. This is a description of the licence text, not legal advice; if your organization has specific obligations around patent clauses or attribution, have counsel read the LICENSE file rather than relying on a summary.
The maintenance picture is a single data point: the last push recorded for the repository is 2026-09-09, and no releases were retrieved. No releases means there is no versioned artifact to pin to at the repository level, though individual crates do appear on crates.io, which implies some publishing cadence exists. The README also notes that the project accepts backers through Open Collective, and the roadmap lists a feedgen admin client as the one unchecked item.
What to verify first, concretely: read the warning block at the top of the repository README and decide whether pre-1.0 churn is acceptable for your timeline. Then read the README for each crate you intend to depend on, since those are the documents that would carry API details. Then read the README for the specific service you intend to run, since the top-level README gives no configuration keys. If you need a PDS and cannot run Postgres, S3-compatible storage and Mailgun, rsky-pds is not the right starting point, regardless of how the rest of the stack looks.
Editorial conclusion
Adopt rsky if you are building AT Protocol tooling in Rust and can accept pre-1.0 churn, or if you want a PDS whose state lives in Postgres and S3-compatible storage rather than SQLite and local disk. Do not adopt it as a drop-in replacement for the canonical TypeScript implementation without reading each service's own README first. Before committing, read the warning at the top of the repository README, check the per-crate READMEs for the crates you intend to depend on, and confirm which services expose a working configuration path, since no releases were retrieved for this repository.
Community notes