A self-hosted social network is a social platform you run on a server you control, usually joined to the wider fediverse through ActivityPub. You set the rules, own the data, and still talk to people on other servers.
It is one branch of the broader self-hosted community movement, where groups run their own tools instead of renting space on a large platform.
What “self-hosted” means for social networking
On a traditional social network, one company runs the servers and decides what stays online. Wikipedia describes the contrast this way: a traditional service hosts all its content on servers managed by the site owner, while the decentralized structure of the fediverse lets any individual or organization host a social platform of their own.
The term itself is a blend of words. According to Wikipedia’s fediverse entry, “Fediverse” is a portmanteau of federation and universe, and most platforms in it are free and open-source software that connect servers using the ActivityPub protocol.
Self-hosting therefore does not mean isolation. The Mastodon documentation states that users are not isolated on their own server, and that they can follow anyone on any other server, and be followed back, as if everyone shared one server.
Which software can run a social network?
Different projects cover different styles of social use. Because they share ActivityPub, they can often talk to each other. The fediverse entry gives examples: a Misskey user can view and interact with posts from Mastodon users, and a Lemmy user can interact with posts from an instance of mbin, a similar service, as well as microblog statuses from Mastodon.
| Style | Example software | Typical use |
|---|---|---|
| Microblogging | Mastodon, Misskey | Short posts, follows, boosts |
| Link aggregation | Lemmy, mbin | Topic communities and discussion threads |
| Social profiles | Friendica | Longer posts and a Facebook-like feed |
Cross-software examples in the table follow Wikipedia’s fediverse entry, which describes Mastodon, Misskey, Lemmy, and mbin interacting across instances.
Matching software to purpose matters more than popularity. A family that wants to share photos and short updates needs a different tool from a hobby group that wants threaded topic boards. A microblogging server centers on individual accounts and a timeline. A link-aggregation server centers on communities that members subscribe to. A profile-style server gives each person a richer page, closer to older social networks. Trying a throwaway instance on a spare machine, or on a small test domain, shows quickly which interface suits the people who will use it.
Federation also shapes what a small server feels like. A brand-new instance with a single user has an empty local timeline, so the experience depends on following people elsewhere. Relays, hashtags, and following active accounts fill the feed over time. An invite-only group server, by contrast, may be useful with only a handful of members, because the conversation happens inside the group.
A discussion-first community may be better served by dedicated forum software, which trades federation for deeper threads and more mature moderation tools. The choice depends on whether the goal is a connected feed or a self-contained meeting place.
Reasons to run your own server
The Mastodon documentation lists its own case plainly: “Your server is your property, with your rules.” In practice the motives usually fall into a few groups:
- Control. Policies, themes, and data retention are the administrator’s decision, not a platform’s.
- Scale of your choosing. The same documentation says a server can be limited to a single user as a personal microblog, kept invite-only for family or friends, or opened so anyone can sign up.
- Continuity. A club, school, or neighborhood group is not exposed to a third party changing its terms.
- Learning. Running a service teaches DNS, backups, updates, and email delivery.
The real work: moderation and upkeep
Hosting is the easy part to describe and the harder part to sustain. Mastodon’s guide warns that providing a public internet service involves moderation work and community management, and that this work becomes more complicated the larger a server grows.
Federation adds a twist. The fediverse entry notes that moderators are responsible not only for content posted by local users but also for content posted by users of other instances. A public server therefore needs written rules, a way to handle reports, and a policy for blocking other servers that cause harm.
Technical upkeep is steady rather than dramatic: applying security updates, testing backups, watching disk space for uploaded media, and keeping a domain and certificate current. A one-person private instance needs little of this; a public one needs a plan for when the administrator is unavailable.
Costs, risks, and trade-offs
Self-hosting swaps one set of dependencies for another. There is no platform to blame when something breaks, and the administrator carries the responsibility for the data of every member. Several trade-offs are worth weighing before committing.
- Time. Updates, backups, and reports arrive on their own schedule. A hobby server can quietly turn into a standing commitment.
- Money. Costs usually come from a virtual server or home machine, a domain name, storage for media, and possibly outbound email. Media storage tends to grow faster than expected.
- Reach. A small server has few local users, so discovery depends on federation working well and on the administrator following others.
- Legal duties. Hosting other people’s posts can create obligations around illegal content, takedown requests, and personal data, which vary by country. Check local rules before opening registration.
- Succession. If the administrator disappears, members lose their accounts. A named backup administrator and a documented export routine reduce that risk.
Managed hosting from a third party can reduce the technical load, but it shifts some control away again. Whether that bargain is acceptable depends on how much the group values owning the whole stack, and no setting makes it free of effort.
Questions to settle with the group
Before launching, it helps to agree on what the server is for, who may join, what happens to content that breaks the rules, and how members will be told about downtime or shutdown. Writing those answers down, even in a short page, prevents most later disputes.
A sensible way to start
- Decide the audience. Solo, invite-only, or open registration changes everything that follows.
- Pick software that matches the style of conversation, using the table above.
- Start small and private. A single-user or invite-only instance is a low-risk way to learn the update and backup routine.
- Write the rules first if anyone else will join.
- Read broadly. The self-hosting resources page collects guides for servers, backups, and maintenance.
Each project’s own installation documentation is the authority on current requirements, and it changes between releases, so check it before choosing a machine.
Frequently asked questions
Can people on other servers see my posts?
Generally yes. Federated software lets users on different instances follow and interact with each other, as long as neither server has blocked the other.
Do I have to open registration to everyone?
No. Mastodon’s documentation says an administrator can run a server alone, keep it invite-only, or let anyone sign up.
Is every fediverse platform based on ActivityPub?
Nearly all are. Wikipedia notes that Diaspora is the only actively developed project under the original definition of the fediverse that does not support ActivityPub.
Is running a server a lot of work?
That depends on size. A private instance is light, but Mastodon’s guide cautions that moderation and community management grow more complicated as a public server grows.
