A self-hosted community is an online group whose forum, chat or social platform runs on software and a server its own organisers control, rather than on a company’s platform. Running one means choosing software, operating a server, securing it and moderating people.
What a self-hosted community actually is
A self-hosted community has three layers. The first is the software that provides discussion, messaging or social features. The second is the server, whether a rented virtual machine, a machine at home or a managed container. The third is the group of people who use it and the rules they agree to. Hosted platforms bundle all three and decide the terms. Self-hosting hands the first two to the organisers, who then take responsibility for the third.
The appeal is control. An operator decides what data is stored, how long it is kept, who can join, which features exist and when an upgrade happens. A community that depends on a commercial platform can lose its archive, its audience or its tools when the platform changes direction. The cost of control is labour: updates, backups, spam, outages and disputes all land on the operator.
The software falls into several families. Classic discussion tools are covered in more depth in the guide to forum software, and the older threaded format is explained in the entry on the bulletin board. Federated tools connect many independent servers, a model examined in the overview of the self-hosted social network. Real-time chat systems such as Matrix sit alongside both. Each family suits a different kind of group, and the choice shapes the rest of the work.
Closed, open and federated communities
A closed community lives on one server and talks to nothing else. Members register, post and read in one place. This is the simplest model to operate and to moderate, because everything that appears on the site was posted by someone who registered there.
A federated community is different. The Fediverse article on Wikipedia describes the term as a portmanteau of federation and universe, and notes that most platforms in it are based on free and open-source software that connects servers through the ActivityPub protocol. A user on one server can see and interact with posts from another. The wider ecosystem is mapped in the fediverse hub, and the wider range of tools in the open source social network overview.
The standard behind much of that connectivity is recent. According to Wikipedia, the W3C presented ActivityPub as a recommended standard in January 2018, and by 2019 almost all software that had used the older OStatus protocol had added support for ActivityPub. Matrix takes a related approach for chat: its own introduction calls it an open standard for interoperable, decentralised, real-time communication over IP, in which every message sent in a room is synchronised to the other servers taking part in that room.
Choosing software for a self-hosted community
Software choice should start with the community, not the technology. A support forum for a product needs searchable, long-lived threads. A neighbourhood group may want quick conversation and event notices. A hobby collective may want to join a wider network of strangers. Those needs point to different tools, and the decision is easier when the operator writes down who will use the space and what they will do there.
A broader community platform overview compares the categories. Two widely used open-source projects illustrate the range, and both publish their requirements openly.
Discourse: a forum-style platform
Discourse is a discussion platform whose GitHub repository describes it as free, open and simple. The repository lists the GPL-2.0 license and shows 48.1k stars and 9.1k forks, a rough indicator of how much attention and contribution the project receives. Its documented architecture is a Ruby on Rails back end API, an Ember.js front end that communicates with the Rails API, PostgreSQL as the main data store and Redis as a cache and for transient data.
For production use, the project’s cloud install guide promises that Discourse can be set up in about 10 minutes with zero knowledge of Rails or Linux shell, using a single command on a fresh Ubuntu or Debian server. The installer adds Docker and git if they are missing and starts an interactive setup wizard. Such claims describe the installer, not the long-term workload. Updates, backups and moderation still follow the install.
Mastodon: a federated microblogging server
Mastodon is the best-known federated microblogging server. Its repository states that Mastodon is free, open-source software licensed under AGPLv3, and the page shows 50.5k stars. The listed technology stack is Ruby on Rails for the REST API and web pages, PostgreSQL as the main database, and Redis and Sidekiq for caching and queueing. The requirements section names PostgreSQL 14+, Redis 7.2+, Node.js 24+ and FFmpeg 5.1+ as versions the project expects. Because a federated server must talk to many others, it carries more moving parts than a single-site forum. The practical steps appear in how to run a mastodon instance.
Matrix and other options
Matrix suits groups that mainly want chat rooms. Its introduction says users can participate in rooms created on any Matrix server because each server federates with others. Pleroma, Misskey, Pixelfed, PeerTube, Friendica, Lemmy and Mobilizon are other names Wikipedia lists among popular Fediverse software, covering microblogging, image and video sharing, social networking, social news and events. Lemmy in particular saw a surge in growth during the 2023 Reddit API controversy, as users looked for alternatives.
Licences matter more than they seem
Mastodon’s AGPLv3 and Discourse’s GPL-2.0 are both copyleft licences, but they differ in an important way for operators. The GNU project describes the Affero licence as designed to ensure cooperation with the community in the case of network server software, and it requires the operator of a network server to provide the source code of the modified version running there to the users of that server. A community that only runs unmodified releases has little to worry about. One that patches its software and exposes it to users should read the licence first and publish its changes.
Server requirements and setup
Hardware needs depend on the software and the audience. Discourse publishes concrete numbers in its install guide: a minimum of 1 GB of RAM with swap and a recommendation of 2 GB or more, a minimum of 1 CPU core against a recommended 2 or more, and a minimum of 10 GB of disk against 20 GB or more recommended. The guide lists a 64-bit Linux operating system as the minimum and Ubuntu LTS as the recommendation. A small forum fits comfortably in those limits. A busy one, or any site that stores many uploaded images and videos, will outgrow them, and disk is usually the first resource to run short.
Domain, DNS and ports
A community needs a stable address. The Discourse guide advises buying a domain from a registrar and creating a DNS A record that points a subdomain, such as a forum address, to the server’s IP address. It warns that DNS propagation can take up to 48 hours, though it is usually much faster. The installer also checks that ports 80 and 443 are available and confirms that the domain resolves to the server before it continues. Operators who plan to federate should pick the domain with care, since many federated systems tie account identities to it and changing it later can be painful.
Email and outside dependencies
Most community software relies on email for registration confirmations, password resets and notifications. Reliable delivery is often harder than installing the software, because mail providers judge new senders strictly. The Discourse guide offers a shortcut for operators who do not want to configure mail: skip SMTP and let users log in through Discourse ID with social logins. Whether that trade suits a given community depends on how much it values independence from large identity providers, which is the reason many groups self-host in the first place.
Choosing where to host
The Discourse guide says its installer works on any Docker-compatible cloud provider or local server. That flexibility extends to most modern projects. A rented virtual server gives a public address, steady bandwidth and easy rebuilds. Hardware at home gives full physical control but depends on residential connections, power and often an ISP that discourages inbound services. A managed provider removes server work but reintroduces dependence on a third party. A fair approach is to start on a rented server, keep configuration in version control, and make sure the community’s data can be exported and restored elsewhere.
Planning for growth is easier when the operator watches a few signals from the start: memory pressure, free disk space, the length of background job queues and the time pages take to load. A forum that slows down at busy hours usually needs more memory or a faster disk before it needs a bigger plan. Resizing a rented virtual server is routine, but it is far calmer when a recent backup exists and members have been warned of a short maintenance window.
Further reading on tooling, tutorials and checklists is collected in the self-hosting resources list.
Security, updates and backups
A public server is scanned for weaknesses within hours of going online, so security work belongs in the first day, not the first incident. Three habits cover most of the risk: strong access control, prompt updates and tested backups.
Locking down access
Mastodon’s documentation for preparing a machine, written for Ubuntu 22.04, gives a blunt instruction: do not allow password-based SSH login and use keys only. It adds a caution to confirm that key login works first, otherwise the change will lock the administrator out. The same logic applies to the application’s own accounts. CISA’s guidance on strong passwords defines them as at least 16 characters long, random, whether as a mix of upper and lower case letters, numbers and symbols or as a passphrase of 5 to 7 unrelated words, and unique to one account. CISA also advises pairing passwords with multifactor authentication and providing a password manager. Administrators of community servers hold more power than ordinary members, so those rules matter most for them.
CISA cites the National Cybersecurity Alliance’s Oh, Behave! survey, in which 35% of participants still used personal details such as pet names or family members in their passwords. A community that invites the public to register will meet that habit often. Requiring long passwords and offering optional multifactor login for members protects the whole site from account takeovers that lead to spam or impersonation.
Updates
The Discourse guide strongly recommends enabling automatic security updates on Ubuntu or Debian and installing fail2ban for brute-force protection. It also describes upgrading Discourse through a web interface, which it calls the recommended route, or through a command line rebuild. The operating system and the application need updating on separate schedules, and neither should be left to chance. Subscribing to the project’s security announcements is a free way to learn about urgent fixes.
Backups and exit plans
A backup that has never been restored is only a hope. Operators should store copies away from the live server, schedule them, and rehearse a restore on a spare machine at least once. They should also write down where the configuration lives and how DNS would be repointed. A community that can rebuild itself in an afternoon survives a failed disk, a hosting dispute or a compromised server. One that cannot may not survive.
Moderation, governance and federation
Software does not run a community; rules and people do. Self-hosted operators carry legal and social responsibility for what appears on their servers, so moderation planning should come before the first public invitation. A detailed treatment appears in the community moderation guidelines, and the main principles are short.
- Publish clear rules in plain language before opening registration, and explain what happens when they are broken.
- Recruit several moderators so that one person’s absence does not leave the site unattended.
- Keep a record of significant moderation decisions, so that later disputes can be judged against precedent.
- Decide in advance how members can appeal, and who handles appeals.
- Choose registration style (open, by approval or by invitation) to match the amount of moderator time available.
Federation changes the workload
Wikipedia notes that moderating a Fediverse instance differs significantly from moderating a traditional social media platform, because moderators are responsible not only for content posted by local users but also for content posted by remote users on other instances. A federated operator therefore decides which other servers to connect to, which to limit and which to block, as well as what its own members may say. Newcomers should read how established servers publish their blocklists and policies before copying them.
Federation also affects privacy promises. A post sent to another server is copied there, and the originating operator cannot reliably delete it. Members should be told this plainly during sign-up, not discovered after a dispute.
Money, time and succession
Self-hosted communities fail more often from tired organisers than from technical faults. The operator should estimate monthly hosting and domain costs honestly, decide whether members will contribute, and keep finances separate from personal accounts where possible. Documentation of passwords, registrar logins and server access should be shared with at least one trusted second administrator. The project should have a stated plan for what happens if the founder leaves: hand-over, archive in read-only mode, or an orderly shutdown with notice to members.
A practical starting sequence
- Write a one-paragraph purpose statement and the first draft of the rules.
- Pick software that matches the format and the available technical skills.
- Rent a modest server, set up a domain and lock down remote access.
- Install the software, configure email, and enable automatic security updates.
- Test backups and restores before inviting anyone.
- Open to a small founding group, adjust the rules, then grow.
Frequently asked questions
What is a self-hosted community?
It is an online community whose software runs on a server the organisers control, whether rented or owned, instead of on a commercial platform. The organisers manage the software, data, security and moderation themselves.
How much server power does a small self-hosted forum need?
For Discourse, the project’s install guide gives a minimum of 1 GB of RAM with swap, 1 CPU core and 10 GB of disk, and recommends 2 GB or more of RAM, 2 or more cores and 20 GB or more of disk. Other software has different needs, so check each project’s documentation.
Is self-hosting a community cheaper than using a platform?
Not always. Server and domain fees are often modest, but the operator’s time for updates, backups and moderation is the larger cost. Self-hosting is chosen mainly for control over data, rules and features.
Do operators have to publish their source code?
Only in some cases. The GNU Affero General Public License requires the operator of a network server to provide the source code of a modified version running there to the server’s users. Operators of unmodified software generally have nothing extra to publish, but they should read the licence of each project they run.
