There Are No Instances in ATProto: What Decentralization Without Servers Means for Your Product

The Mental Model We Keep Getting Wrong

When people first hear "decentralized social network," they usually picture Mastodon: you sign up on a server, that server is your home, and your identity lives there. Pick the wrong instance and you're stuck migrating later. Email works the same way. Your address belongs to whoever runs the mailbox.

Dan Abramov's article makes a sharp point about ATProto, the protocol that powers Bluesky: that model doesn't apply here. There are no instances. There's no server you join and live inside. The architecture pulls identity, data storage, and the application layer apart so that no single server owns you.

If you're carrying the Mastodon model into ATProto, you'll misjudge how the whole system behaves, including where the real lock-in risks are.

That sounds like protocol trivia. It isn't. The way a system handles identity and data ownership shapes everything downstream: migration, moderation, cost, and how much leverage any one company has over your users.

How ATProto Actually Splits Things Up

The core idea is that the pieces you'd normally bundle into one "server" are separated into independent roles:

• Identity lives with the user, anchored to a portable identifier (a DID) rather than to one host. Your handle can point at different infrastructure over time without your identity changing.
• Personal data sits in a repository that can be hosted anywhere and moved without losing your followers or history.
• The network view (search, feeds, the firehose of activity) is assembled by services that aggregate data across the whole network rather than per-server.

Because these layers are decoupled, "which instance are you on?" stops being a meaningful question. You aren't on an instance. You have an identity and a data repository, and applications read from the broader network.

Why This Matters If You're Building Something

Most founders I talk to don't care about protocol purity. They care about three things: keeping users, controlling costs, and not getting trapped by a vendor. ATProto's design speaks directly to all three.

Portability is a feature, not a migration project. In an instance-based world, moving providers means rebuilding your social graph and often losing history. When identity and data are decoupled from the host, switching infrastructure becomes closer to changing a DNS record than to starting over. If you're designing a product where users invest years of content, that difference is the whole ballgame.

The lock-in moves somewhere new. No instances doesn't mean no lock-in. It just relocates it. The heavy lifting in ATProto happens in the aggregation layer, the services that index the entire network. Running that is expensive and concentrates power. So the honest question for a builder isn't "is this decentralized?" It's "which layer is actually hard to replace, and who controls it?"

Your architecture decisions echo for years. Whether you build on a protocol like this or roll your own, the choice of where identity lives and who can move data is one of the hardest things to change later. It's worth getting right before you have a million users, not after.

The Practical Takeaway

You don't need to adopt ATProto to learn from it. The useful lesson is structural: separate identity from storage, and separate storage from the application that reads it. Products that bundle all three into one account on one server are easy to ship and hard to leave, which is great for the company right up until users want out or regulators start asking questions.

When I evaluate a system for a client, I ask a few blunt questions:

• If a user wanted to leave tomorrow, what could they take with them, and what would break?
• Which component is genuinely expensive to operate, and does that create a dependency we can't escape?
• Are we conflating "identity" with "the database row that happens to hold this user today"?

Those questions surface the same trade-offs ATProto is built around, regardless of your stack.

Where I Come In

Most of my work sits at the intersection of these architectural calls and the AI systems and products built on top of them. Whether you're designing a new social or networked product, weighing build-versus-adopt on a protocol, or trying to reduce platform lock-in before it calcifies, the decisions about identity and data ownership deserve real scrutiny early.

If you're thinking through how to structure a product so it stays portable, affordable, and defensible as it grows, that's exactly the kind of problem I help teams work through. Worth a conversation before the architecture hardens.