The self-hosting resources a community needs are a small Linux server, a domain name, working outgoing email, a backup routine, and someone with the time to patch and moderate it. Hardware is the cheap part. Ongoing attention is the real cost.
This guide supports the wider self-hosted community overview, and breaks the requirements into server, domain, email, security, people and budget.
Self-hosting resources: how much server is enough
Forum and social software has modest minimum needs. The Discourse cloud install guide lists a minimum of 1 GB of RAM (with swap), 1 CPU core and 10 GB of disk, and recommends 2 GB+ of RAM, 2+ cores and 20 GB+ of disk. It specifies a 64-bit Linux system, with an Ubuntu LTS release as the recommended choice.
The minimum is a starting line, not a plan. A small group of friends can run on it. A public community that attracts image uploads, search crawlers and a steady base of active members will outgrow it, and the first symptom is usually slow page loads during busy hours rather than a crash. Treat the recommended column as the realistic floor for anything open to the public.
| Resource | Minimum | Recommended |
|---|---|---|
| RAM | 1 GB (with swap) | 2 GB+ |
| CPU | 1 core | 2+ cores |
| Disk | 10 GB | 20 GB+ |
| Operating system | 64-bit Linux | Ubuntu LTS |
Table figures are taken from the Discourse installation documentation.
The same guide notes that its installer works on any cloud provider with Docker support, and it names DigitalOcean, AWS EC2, Google Cloud Platform, Linode/Akamai, Vultr and Hetzner, plus any VPS with root SSH access. That list matters for one reason: the software is not tied to a vendor, so the choice of host can be made on price, location and reputation. Hosting a community at home is possible, but residential connections often block inbound ports and change addresses, so a rented virtual server is the simpler route.
Domain name and DNS
A community needs an address people can remember and that survives a change of server. Buying a domain gives control: if the server is rebuilt or moved, only a DNS record changes and members never notice. A domain from a registrar costs little each year compared with the server.
For testing, shortcuts exist. The Discourse installer offers free subdomains such as yoursite.discourse.diy, which suits hobby projects and learning. The install guide describes a 6-digit verification code valid for 10 minutes, after which the installer creates the DNS record itself. A borrowed subdomain is fine for a trial, but a community meant to last is better served by a name it owns, because members, links and email reputation all attach to the address.
Email: the part people forget
Almost every community platform sends mail for sign-up confirmation, password resets and notifications. A server that cannot send reliable email produces a community that members cannot join. The Discourse guide treats this as optional at install time: it says users can log in through Discourse ID with social logins such as Google, Facebook, Apple and GitHub if SMTP is skipped.
That workaround suits a quick test. For a permanent community, a dedicated transactional email service or a properly configured SMTP relay is the safer choice, because mail sent straight from a new virtual server is frequently treated as spam. Setting up SPF and DKIM records on the domain is the standard way to prove the mail is legitimate. Budget an afternoon for this step and send test messages to several providers before opening registration.
Security basics before launch
A public server is probed by automated scanners within hours of going online. The Mastodon documentation, in its guide to preparing a machine, gives a compact hardening checklist, written with Ubuntu 22.04 in mind. Its main steps are:
- Do not allow password-based SSH login. Use keys only, after confirming that key login already works so the administrator is not locked out.
- Update system packages before installing anything else.
- Install fail2ban so repeated login attempts are blocked.
- Install a firewall and only allow SSH, HTTP and HTTPS ports.
These steps apply to any platform, not only Mastodon. They take under an hour and remove the most common ways small servers are compromised. Automatic security updates and a habit of reading the project’s release announcements cover most of the rest.
Backups and recovery
A community is mostly its data: posts, accounts, uploads and settings. Backups protect against disk failure, a bad upgrade and a mistaken deletion. A workable routine has a few parts:
- Automated database dumps and upload copies on a schedule.
- A copy stored away from the server, ideally with a different provider.
- A restore test on a spare machine, because an untested backup is only a hope.
- A written note of where configuration, secrets and DNS records live.
Many hosts sell snapshots of the whole server. Snapshots help, but they live with the same provider and may capture a database in an inconsistent state, so they work best as an addition to application-level backups rather than a replacement.
The human resources: time, skills and moderation
The hardest requirement does not appear in any specification table. Someone must apply updates, watch disk space, answer member questions and deal with abuse. Software upgrades arrive regularly, and security fixes cannot wait for a convenient weekend. A single administrator is a single point of failure, so a second person with access and a shared runbook is worth more than a bigger server.
Moderation also takes time. Spam, harassment and disputes arrive as soon as a community has members, and a self-hosted site has no trust-and-safety team behind it. Written community moderation guidelines let volunteers act consistently and give members something to point to when decisions are challenged.
Federated platforms add a further duty: the administrator decides which other servers to connect with or block. Anyone weighing that model can compare it with the options covered in the guide to a self-hosted social network.
Budgeting and a sensible first step
Costs fall into recurring items: the server, the domain, email delivery, off-site backup storage and, for larger groups, extra storage for media. None of these is large for a small community, but they repeat every month or year, so someone has to commit to paying them. Agreeing in advance how the bill is covered, whether by the founder, donations or member contributions, avoids the common failure in which a site disappears because one person loses interest or money.
A sensible path is to start small. Rent a server at the recommended specification, claim a domain, set up email properly, apply the hardening steps, schedule backups and test a restore. Invite a handful of members, learn the upgrade routine, and only then open the doors. Growth can be handled by resizing the server, which most providers allow without a rebuild.
Frequently asked questions
What is the smallest server that can run a community?
A small Linux virtual server can host a modest forum. Anything open to the public is safer on the recommended specification in the table above than on the bare minimum.
Is a domain name required?
Not for testing, since the Discourse installer can provide a free subdomain. A community intended to last is better off with its own domain, which can be pointed at a new server later.
Can a community run without email?
For a trial, yes. The Discourse guide says users can sign in through social logins if SMTP is skipped. A permanent community should set up reliable email for resets and notifications.
What is the first security step on a new server?
The Mastodon documentation starts by disabling password-based SSH login so that only keys work, then updating packages, adding fail2ban and restricting the firewall to SSH, HTTP and HTTPS.
