Mastodon vs Bluesky vs a Private Network: Which Model Fits

Mastodon, Bluesky and a private network answer the same question in three different ways: who is in charge of identity, moderation and money? Mastodon spreads those decisions across many independent servers. Bluesky splits them across separate services on an open protocol. A private network puts them with one operator.

None of them is the better choice in general. This post sets out how each works, what each costs you, and which kind of project fits which. If you decide on a closed, branded network you control, a white-label Twitter clone is the ready-made version of that model.

Three models in one paragraph each

Mastodon: many servers, one protocol

Mastodon's documentation describes it as microblogging software and federation as the way separate services interoperate, so a person can mention or follow someone on another site by using their address. It uses ActivityPub, which the documentation calls a standardized, open protocol for federation. The wider set of software that speaks ActivityPub is called the fediverse and includes projects other than Mastodon.

Each server is its own entity. The joinmastodon.org site says each server creates and enforces its own rules locally rather than from the top down, and that feeds are chronological with no algorithms or ads. The software is free and open source and developed by a non-profit organization.

Bluesky: an open protocol with separate roles

Bluesky runs on the AT Protocol. The protocol overview describes decentralized identifiers paired with domain-name handles, and signed data repositories that hold a member's posts, likes and follows. Three network services do the work: personal data servers that host an account's data and identity, relays that gather updates from many servers into one stream, and app views that provide aggregated counts and discovery. Feed generators and labelers add custom feeds and moderation.

Two ideas stand out. First, account portability: a member can move to a new provider without the old server's cooperation. Second, the protocol separates "speech" from "reach", meaning the base layer is permissive while aggregation services decide what gets amplified. Bluesky's about page adds that members can choose among feeds and control what appears in their timeline with moderation lists and filters.

A private network: one operator, one database

A private network is the model most people already know from commercial social apps. One operator runs the software, owns the database, writes the rules and takes the payments. Members need an account with that operator. There is no federation to configure, and no outside server can reach in. You choose whether to run it on your own infrastructure or have a vendor deploy a packaged build for you.

Comparison table

The rows below cover what an operator tends to care about. Statements about Mastodon and the AT Protocol come from their own documentation. The private network column describes the model in general, with our product's behavior noted where it applies.

What federation costs you

Federation sounds like pure upside: your members can talk to people elsewhere, and nobody owns the network. The costs show up on the operations side.

Moderation across servers

The Mastodon moderation documentation describes limiting or suspending an account, rejecting media from a remote domain, limiting a domain and suspending a domain, plus importable blocklists. It also says all of this is applied locally and does not change how other servers treat those accounts. In practice, a post from a server you have never heard of can reach your members, and your only defenses are the tools on your own server.

Inconsistent search and counts

On a federated network, no single index holds every post. A search on your server finds what your server has seen. Counts of followers or replies can differ between servers. That is acceptable for a community, and awkward for a business that wants to show an advertiser one reliable number.

No central ad or payment layer

The ActivityPub specification covers a server-to-server federation protocol and a client-to-server protocol. It defines actors with inboxes and outboxes, and activities such as create, follow and like. It says nothing about subscriptions, ads or payouts. If you want money to move on a federated server, you add it yourself, and it will not federate.

Support load

A public server with open sign-up becomes the support desk for strangers. The Mastodon scaling guide lists web, streaming and background-job processes, a PostgreSQL database and Redis, with advice on connection pools, read replicas and media retention. A server for twenty friends needs little of that. A server for twenty thousand people needs an on-call plan.

A worked example

Say you run a federated server for a regional hobby community of 2,000 members. Say 5 percent of them file at least one report a month. That is 100 reports, and if each takes ten minutes to read, check and answer, you spend over sixteen hours a month on reports before you count remote servers' content, spam sign-ups or a bad week. These numbers are invented to show the shape of the cost, not to predict yours. The point is that the work scales with members, and federation adds a stream of content you did not invite.

What a closed network costs you

A private network moves that same work to you, and takes away the free audience.

• You carry trust alone. Members rely on your word that data is safe and rules are fair. There is no wider community to switch to, so a mistake is your reputation.
• You carry moderation alone. A report queue, an audit trail and named moderators are your duty from the first day. Our microblogging launch checklist covers what to set up before you open.
• You carry infrastructure alone. Hosting, backups, media delivery and security review are your bills.
• You have no instant audience. A new member sees only the people who joined. Seeding is your job, as the niche social network guide explains.
• You must handle exits. Without portable identity, members who leave lose their history unless you offer an export.

What you get in return is a clean business. One database means one set of rules, one set of numbers for advertisers and one place to attach payments. If money is part of the plan, the Twitter clone business model page lays out how tiers, ads, tips and creator subscriptions fit together on a closed network.

Which fits which project

For the paid creator case, our other lead products show the same logic in other media: a ready-made OnlyFans clone for subscription content and a TikTok clone script for short video both assume one operator who owns payments and rules. Federated protocols are a poor fit for them for the same reason.

What the first week looks like

The models differ most in what you do before anyone arrives. On Mastodon, you install or rent a server, write server rules and invite people, who can also follow accounts elsewhere, so the timeline is not empty even if your own members are few. On Bluesky, you pick a role: a feed, a labeler, a client or a hosting service, and you publish it for people to choose. On a private network, you brand it, switch on moderation and seed it with real people, because every new member sees only what you have put there.

That last point is the real price of control. A closed network with no members is a blank page, and a blank page does not retain anyone. Plan the first fifty accounts by name, and plan the first week of conversation, before you pick the software. The reasoning is the same one we use in the community cold start problem guide.

Mixed approaches

The three models are not sealed. A few patterns exist, and each has a cost.

• Federate later. Run a closed network, then add ActivityPub support if outside reach becomes important. This is a project, not a setting. We set up federation with other servers for your build as tailored work (2 to 8 weeks); confirm scope with us at kickoff.
• Bridge. Mirror selected public posts to another network through a bridge. You keep your database, and you inherit the moderation burden for what comes back.
• Join, then leave. Start on an existing Mastodon server or Bluesky community, learn what your members want, then move to a private network. Mastodon documents moving and leaving accounts, and Bluesky's protocol is built around portability. Your members will not all follow.
• Export by default. If you stay closed, offer members a data export and publish it as a promise. It costs little and answers the most common fear about closed networks.

If you are comparing the commercial apps rather than the models, see X vs Bluesky vs Threads, and for the question of how a big commercial app connects to the fediverse, does Threads work with Mastodon.

Identity, exports and leaving

Members rarely ask which protocol you use. They ask what happens to their account if they leave, if you shut down or if you ban them unfairly. The three models answer differently, and your answer is part of your pitch.

• Mastodon: an account lives on one server and is addressed through it. The documentation has pages on moving or leaving an account, so there is a defined path, though it depends on the old server still existing.
• Bluesky: the AT Protocol overview says a member can move to a new provider without the old host's cooperation, using rotation keys to update the identity record, and that backups allow recovery if a data server disappears. That is the strongest portability claim of the three.
• Private network: portability is whatever you build. A data export, a clear deletion process and a published shutdown notice period are the minimum a fair operator offers.

A closed network can still be trustworthy. Say what you store, who can read it, how long you keep it and how a member leaves. Our Twitter clone keeps login history, privacy preferences and account status as records, and retention duties in your market stay with you as operator; this is not legal advice, so ask counsel what applies where you operate.

Who can say no

The cleanest way to compare the models is to ask who can remove a member and who can overrule that. On Mastodon, the server administrator removes an account from the server, but the person can usually start again elsewhere. On Bluesky, a service can refuse to show someone, but identity belongs to the member. On a private network, you can remove a member entirely and nobody can overrule you. That power is the point for some projects and the danger for others. Write an appeal process either way.

Money by model

Revenue is the sharpest difference. Say a niche network has 1,000 active members, and say 3 percent pay 5 a month for a tier. That is 30 payers and 150 a month before processor fees. On a private network you can charge that, keep the money and spend it on moderation. On Mastodon you would collect donations or run a separate payment page outside the protocol. On Bluesky you would build a service on top and charge for it. The numbers are an invented example. What changes with the model is whether the revenue is built in or bolted on. Our guide to how creator platforms make money goes through the options.

Decision checklist

Answer these in order. The first "yes" that matters to you usually settles it.

1. Must members be able to leave with their audience? If yes, favor Bluesky's portability or Mastodon's move process.
2. Must you earn from the network directly? If yes, favor a private network.
3. Must the network be one voice among many? If yes, favor federation.
4. Can you staff moderation for content you did not invite? If no, avoid open federation.
5. Do you need a single set of numbers for advertisers or investors? If yes, favor a private network.
6. Do you need to start tomorrow with zero budget? If yes, join an existing server and learn first.
7. Do you need an iOS and Android app under your own name? If yes, plan for your own build or a packaged one.
8. Does a regulator or customer require audit trails and account controls? If yes, favor a private network.

Glossary

• Federation: separate services exchanging posts and follows so members on one can interact with members on another.
• ActivityPub: a W3C Recommendation, published in January 2018, defining federation between servers and a client-to-server API.
• Fediverse: the set of services that speak ActivityPub.
• AT Protocol: the protocol under Bluesky, with portable identity and separate hosting, relay and discovery roles.
• PDS: personal data server, the host of a member's account data.
• Relay: a service that aggregates updates from many servers into one stream.
• Labeler: a moderation service whose labels members can subscribe to.
• Domain block: a Mastodon server rule limiting or suspending a whole remote server.

What to decide next

Write down who the network is for and who must be able to say no. If the answer is "the community, and no single company", federation is worth its costs. If the answer is "us, because we answer for the members and the money", build a private network and be honest with members about it. For the closed route, the launch order is in how to start a microblogging platform, the feed design is in how the Twitter algorithm works, and the cost of buying instead of building is on the Twitter clone development cost page.