AT Protocol Architecture: Understanding Instances and Decentralization

The Core Misconception: Protocol vs. Platform

The most common question developers ask when they first encounter AT Protocol is also the most revealing: “Where do I spin up an instance?” The question makes sense. ActivityPub has Mastodon, Matrix has Synapse, Nostr has relays you can run. The mental model of a decentralized social network is a collection of interoperating servers, each one an “instance” that a community or organization runs. ATProto looks, at first glance, like it should work the same way.

It does not.

The AT Protocol (Authenticated Transfer Protocol, or ATProto) is a protocol and set of open standards for decentralized publishing and distribution of self-authenticating data within the social web, as defined in the Wikipedia entry. It is the technical foundation of Bluesky and a growing ecosystem of interoperable social apps collectively called the ATmosphere. But the protocol itself contains no concept of an “instance” in the Mastodon sense. There is no ATProto server software that you download, configure, and point a domain at, the way you would with Mastodon or Lemmy.

This distinction matters because it shapes every decision a developer makes when building on ATProto. If you approach it looking for instances, you will be confused. If you approach it as a set of standards for data exchange, identity, and federation, the architecture becomes clear.

What ATProto Actually Defines: Identity, Repos, and Federation

The official AT Protocol overview describes the protocol as a decentralized system for large-scale social web apps. It defines three lower-level primitives: repositories, lexicons, and DIDs. These are specifications, not server software.

Identity. Users in ATProto have permanent decentralized identifiers (DIDs) for their accounts, plus a configurable domain name that is a human-readable handle. Identities include a reference to the user’s current hosting provider and cryptographic keys. The protocol specifies how DIDs resolve to DID documents, which contain public keys and references to the user’s data repo. Two DID methods are currently supported: did:plc (Bluesky-managed registry) and did:web (domain-based). As the Wikipedia article notes, the did:plc method has been criticized as a potential single point of failure because it relies on a single registry hosted by Bluesky Social, with no system to independently verify a document’s current state.

Data Repositories. User data is exchanged in signed data repositories. These are collections of records (posts, likes, follows, blocks) stored in a Merkle search tree. Each record gets a unique timestamp identifier (TID). Media files are stored separately as blobs. The protocol specifies how repositories are structured, signed, and synchronized, but it does not ship a server that hosts them.

Federation. The AT Protocol has a federated network architecture, meaning account data is stored on host servers rather than in a peer-to-peer model between end devices. Repo data is synchronized between servers over standard web technologies (HTTP and WebSockets). But again, the protocol specifies how synchronization works, not what software does the synchronizing.

Here is a practical example of what the protocol defines at the code level. The following is a simplified illustration of how a record key is constructed in ATProto, using the timestamp identifier format specified in the protocol:

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

fn generateTID(): string {
 const now = Date.now();
 const timestamp = BigInt(now) * 1000n; // microsecond precision
 const clockId = Math.floor(Math.random() * 1000);
 return encodeBase32(timestamp) + encodeBase32(BigInt(clockId));
}

fn encodeBase32(value: bigint): string {
 const alphabet = '234567abcdefghijklmnopqrstuvwxyz';
 let result = '';
 let remaining = value;
 while (remaining > 0n) {
 result = alphabet[Number(remaining % 32n)] + result;
 remaining = remaining / 32n;
 }
 return result.padStart(13, '2');
}
console.log(generateTID());

This is a protocol-level specification. It tells implementers how to construct identifiers that the network can sort and reference. It does not tell you how to run a server.

PDS, Relays, and AppViews: The Service Layer, Not Instances

The three core services in the AT Protocol network are Personal Data Servers (PDS), Relays (formerly Big Graph Services), and App Views. These are the closest thing to “instances” in the ATProto ecosystem, but they are architectural roles, not deployable software packages.

Personal Data Servers (PDS) host user repositories and their associated media. They are the network access point for users, helping repo updates, backups, data queries, and user requests. The protocol’s design results in low computational requirements for PDS operation, allowing individuals or groups to run their own PDSes without significant resources. According to Wikipedia, although most users’ repositories reside in PDSes run by Bluesky Social, many independent PDSes exist within the network.

Relays crawl the network by continuously fetching repo updates from PDSes before aggregating, indexing, and forwarding these updates into network-wide data streams called the firehose. Relays have been criticized as the most centralized component in the protocol’s design, given their near-indispensable role and lack of clear incentives for running one.

App Views are end-user platforms that consume, process, and deliver data from relays to user clients. The largest App View is Bluesky itself, but others exist: Blacksky (supporting Black social media users), Frontpage (a Hacker News-style social news site), and Smoke Signal (an RSVP management service).

The critical insight is that each of these roles is an implementation of protocol specifications, not a built-in feature of the protocol itself. The GitHub repo at bluesky-social/atproto contains reference implementations of these services in TypeScript, including the PDS and App View, but they are development tools and reference code, not turnkey server software you deploy in production.

What Developers Should Expect When Building on ATProto

For developers accustomed to deploying apps on cloud platforms, the absence of instances requires a mental shift. You do not deploy an “ATProto server.” You build software that implements the ATProto specifications. This is a key difference from protocols like ActivityPub, where you can set up a Mastodon instance in under an hour. For a broader look at how infrastructure spending is shaping up for these kinds of decentralized networks, see our Hyperscaler Capex Tracker 2026: Who Is Spending Where on AI Infrastructure.

Here is a realistic example of how a developer would interact with the AT Protocol at the API level, using the XRPC (Cross-organizational Remote Procedure Calls) interface:

import { AtpAgent } from '@atproto/api';

async fn getUserProfile(handle: string) {
 const agent = new AtpAgent({
 service: 'https://public.api.bsky.app'
 });

 try {
 const response = await agent.getProfile({
 actor: handle
 });
 return response.data;
 } catch (error) {
 console.error('Failed to fetch profile:', error);
 return null;
 }
}
getUserProfile('example.bsky.social').then(profile => {
 if (profile) {
 console.log('Display name:', profile.displayName);
 console.log('Description:', profile.description);
 console.log('Followers:', profile.followersCount);
 }
});

This code talks to a running App View (Bluesky’s public API endpoint). It does not spin up an instance. The developer is a client of the network, not a host of it.

If you want to host user data yourself, you would deploy a PDS. The separate repo bluesky-social/pds contains specific directions for self-hosting. But this is not a one-click operation. The self-hosting setup documented in the GitHub repo requires Node.js 22 (managed via nvm) and pnpm package manager, plus Docker for the development environment. You also need familiarity with AT Protocol’s data model.

The developer quickstart from the main repo gives a sense of the setup:

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

# Developer quickstart for ATProto reference impl
# Requires: nvm, Node.js 22+, pnpm, Docker, jq

# Use existing nvm to install Node.js 22 and pnpm
make nvm-setup

# Pull dependencies and build all local packages
make deps
make build

# Run tests, using Docker services as needed
make test

# Run local PDS and AppView with fake test accounts and data
make run-dev-env

# Note: This starts a dev environment with synthetic data.
# Production deployment requires additional configuration for
# DID resolution, relay connectivity, and database persistence.

This is a development environment, not a production deployment script. The ATProto ecosystem is still maturing, and tooling for running independent services is evolving alongside protocol standardization work at the IETF.

Comparison With Other Decentralized Protocols

The difference between ATProto and other decentralized social protocols becomes clear when you compare their deployment models. The table below summarizes how each protocol approaches the concept of “instances” or servers.

The AT Protocol’s microservice architecture is a deliberate design choice. According to the Wikipedia article, compared to protocols like ActivityPub where implementations are typically monolithic servers that host both user data and app logic, ATProto splits these elements into smaller microservices that can be used as needed. This gives more flexibility but also more complexity.

The trade-off is real. ActivityPub’s monolithic approach means anyone can set up a Mastodon instance in under an hour. The price is that moving your account and social graph to a different instance is difficult. ATProto prioritizes account portability: the goal is that a user can migrate their account to a new PDS without the original server’s involvement. But that portability comes at the cost of a more complex deployment model that currently lacks the turnkey server software that made Mastodon successful. Independent PDS hosting is possible, but the setup requires understanding protocol specifications rather than running a single installer.

The Future of ATProto Deployment

The protocol’s general architecture, user repo, and data synchronization specifications are in the process of standardization within the Internet Engineering Task Force (IETF). Further specifications, including data schemas, identity systems, OAuth implementation, and private or limited-visibility data, are under development by Bluesky Social PBC. The broader AI Infrastructure 2026: Market Trends, Supply Chain, and Macro Influences report provides context on how these kinds of protocol-level investments fit into the larger technology landscape.

The IETF standardization process is significant because it moves ATProto from a Bluesky-controlled specification to a community-owned standard. Once the core specifications are finalized, independent implementations are more likely to emerge. The Go language source code in bluesky-social/indigo, which includes a Big Graph Service (relay) implementation, suggests that the ecosystem is already diversifying beyond the TypeScript reference code.

What will “instances” look like in a mature ATProto ecosystem? The most likely pattern is that independent PDS hosts will emerge, similar to how email providers offer mail services without running their own SMTP server from scratch. A user would choose a PDS provider (or run their own), and that PDS would handle data hosting, identity management, and network requests. The user would then access social apps through any App View that supports AT Protocol, taking their identity and social graph with them.

This is fundamentally different from the Mastodon model, where an instance is both the hosting provider and the app. In ATProto, hosting and app are decoupled. That is the architectural promise, but it is also why there are no “instances” in the traditional sense. The protocol does not define instances because it does not need to. It defines how independent services interoperate, leaving the deployment model to implementers.

For anyone evaluating ATProto for a project, the practical advice is straightforward. If you want to build a social app, use client libraries (@atproto/api, @atproto/xrpc) to interact with the network as a client. If you want to host user data, study the PDS reference implementation and understand the identity and repo specifications. If you want to build an alternative App View, consume the firehose through a relay and implement your own aggregation and presentation logic.

Do not look for instances. They do not exist. Look for specifications, and build from there.

Key Takeaways:

• ATProto is a protocol and set of open standards, not a server software package. There are no canonical “instances” in ATProto itself.
• The three core services (PDS, Relay, App View) are architectural roles defined by the protocol, not deployable software instances.
• Existing implementations of ATProto services require significant setup and protocol knowledge, unlike turnkey deployment of ActivityPub servers.
• The IETF standardization process and growing ecosystem (Blacksky, Frontpage, Smoke Signal) point toward more accessible deployment options in the future.
• Developers should approach ATProto as a set of specifications to implement, not a platform with instances to join.

Sources and References

This article was researched using a combination of primary and supplementary sources:

Supplementary References

These sources provide additional context, definitions, and background information to help clarify concepts mentioned in the primary source.

• AT Protocol
• Protocol Overview – AT Protocol
• AT Protocol – Wikipedia
• GitHub – bluesky-social/atproto: Social networking technology created by Bluesky · GitHub
• The AT Protocol | Bluesky