People self-host Matrix to stop a company from holding their conversations, and that part works exactly as advertised. What surprises them later is the shape of the thing they installed: a homeserver is not a private box that happens to speak chat. It is a replication node in a public network, and federation behaves far more like a publishing protocol than most new admins expect.
None of that is an argument against running one — it is the argument for running one deliberately. The privacy you gain is real but specific: custody moves to you, the account cannot be closed by someone else, and legal questions land in a jurisdiction you chose rather than one a company chose. The privacy you do not gain is equally specific, and almost all of it lives in the gap between "the messages are encrypted" and "nobody can tell who is talking to whom". This guide covers both halves, then the operational details that decide whether the server is still healthy a year from now.
What running your own homeserver actually changes
Start by separating the threats, because a homeserver answers some of them completely, some partially, and some not at all. The table below is the honest version of the pitch, and it is worth reading before you pick hardware rather than after.
| What you are worried about | Does your own homeserver fix it? |
|---|---|
| A company reading the contents of your messages | End-to-end encryption already covers this in private rooms — and yes, self-hosting removes the company as well |
| A company profiling who you talk to and when | Partly. You stop feeding one central operator, and your own server now holds that record instead |
| An account closed or suspended by someone else | Yes. The clearest win of the whole exercise, and the least discussed |
| A legal request for your data | It moves rather than disappears. The request now reaches you, under the law of the country you picked |
| Other parties learning your social graph | No. Every server with a member in the room receives the same membership data you do |
| Hiding that the server exists at all | No. Federation needs a public name and a reachable port; it is the opposite of hidden |
Read the last two rows carefully, because they are where expectations break. If your goal is that nobody should be able to establish that a service exists, Matrix is the wrong tool and an onion service is closer to the right one. If your goal is custody, control and jurisdiction, a homeserver is an excellent instrument and the rest of this guide is about running it well.
Federation is a replication protocol wearing a chat protocol's clothes
Here is the mechanic that explains most surprises. When one of your users joins a room hosted elsewhere, your server does not fetch messages on demand like a mail client. It joins the room as a participant in a distributed event graph, then pulls and stores a copy of the room's events, its membership, and enough state history to validate what comes next. From that moment your machine holds a replica, and every other participating server holds one too.
The consequences run in both directions and neither is intuitive. Data your users generate — display name, avatar, joins and leaves, timestamps, reactions — is copied to every server that has a member in that room, and it stays in their databases regardless of what you later delete on yours. Redaction is a request to peers, not a command. There is no unsend across a federation of independently operated servers, and expecting one is the single most common misunderstanding about the protocol.
In the other direction, joining large public rooms means importing other people's history onto your disk. This is why a brand-new homeserver with three users can carry tens of gigabytes of database: not because your three users wrote much, but because they joined rooms with fifty thousand members and years of state. Deliberate room choice is a capacity decision as much as a privacy one.
What encryption covers, and what stays in the clear
Matrix encrypts message content with Megolm, and in private rooms it is on by default. That protects the part people care about most and it genuinely works — your server stores ciphertext it cannot read, which is a real and useful property when the server is rented hardware. The envelope around the message is a different story, and the gap is wider than most summaries admit.
| Signal | Encrypted? | Visible to |
|---|---|---|
| Message text and file contents | Yes | Only the verified devices of room members |
| Who is in the room, and every join or leave | No | Every homeserver with a member in that room |
| Timestamps, message frequency, activity hours | No | Every participating homeserver |
| Display names, avatars, presence and typing | No | Every participating homeserver |
| Room name, topic and avatar | No | Every participating homeserver |
| Attachment size and the timing of the transfer | No | Every participating homeserver |
| Your server's domain and its IP address | No | The entire federation — this is by design |
The practical reading: encryption protects the what, federation publishes the who, when and how often. For most communities that trade is entirely acceptable and the honesty is the point. For a threat model where the social graph itself is the sensitive part, a federated protocol is structurally the wrong shape, and no configuration flag changes it.
Synapse, Dendrite or Conduit — what to actually run
Three implementations matter in practice, and the choice is mostly a resource decision rather than a philosophical one.
- Synapse is the reference server, written in Python, and the only one where every feature works on day one. It is also the hungriest: memory grows with the number and size of rooms your users join, and a busy server eventually wants to be split into worker processes. Choose it when you need spaces, moderation tooling, bridges and admin APIs to behave exactly as documented.
- Dendrite is the Go rewrite. Noticeably lighter than Synapse and perfectly usable for a small server, at the cost of some feature lag. A reasonable middle option when Synapse feels heavy for the number of people you actually have.
- Conduit and its actively developed fork
conduwuitare written in Rust and ship as a single binary with an embedded database. They run a family or small community server on the smallest plan we sell without complaint. The trade is a smaller ecosystem: some admin tooling and a few bridges assume Synapse.
For a first server with a handful of users, Conduit-family software on a small VPS is the least painful path to something that works and stays cheap. For anything you expect to grow — a public community, a company, a project with bridges — start on Synapse and skip the migration, because moving between implementations later is an export-and-rebuild exercise rather than a config change.
The delegation setup everyone gets wrong
Matrix separates the name in your user IDs from the machine that serves the traffic, and getting this backwards is the most common permanent mistake in self-hosting. Your server_name is the domain that appears after the colon in every user ID on your server. It becomes part of your identity in the federation the moment the first event is signed, and it cannot be changed afterwards without abandoning every account and room on the machine.
The setup you almost always want: server_name is your bare domain, while the software runs on a subdomain. You connect the two by delegation, in one of two ways. The simple one is a static JSON file served at /.well-known/matrix/server on the bare domain, naming the real host and port. The alternative is a DNS record, _matrix._tcp, pointing at the same place. Serve the client-side file at /.well-known/matrix/client too, so apps find the homeserver from an address alone.
Decide the name before you install anything. Setting server_name to the subdomain because that is where the software happens to run is the classic error, and it is irreversible: every user ID, room ID and signed event carries it forever. Pick the domain you would want printed on a business card, delegate to wherever the process actually listens, and keep valid TLS on both names — a certificate failure on the delegated host takes federation down even while the app looks fine locally.
Sizing it honestly
Matrix is not CPU-bound in normal operation; it is bound by memory and by database behaviour. The published figures for Synapse are a useful floor: roughly 2 GB of RAM to start, about 4 GB once you have ten to fifty active users, and 8 GB or more past a hundred. Conduit-family servers land far below that. What those numbers omit is that consumption tracks rooms joined, not people registered — five users in a hundred large public rooms cost far more than fifty users in a handful of private ones.
Two practical rules follow. Put the database on fast storage and give it room to grow, because the write pattern is small and constant rather than bursty. And do not size for today's user count: size for the rooms those users will join in the first month, which is usually where the surprise lives. Our entry plan carries a small Conduit or Dendrite server comfortably, while a Synapse instance for a real community belongs on a mid-tier plan or above — the chat hosting page lists the tiers we recommend against each of those shapes.
Uptime matters more here than for most workloads, because a chat server that is down is not merely unavailable — it is silently missing events that peers will retry for a while and then stop offering. Federation is forgiving of minutes and unkind about days.
The media store is a slow-motion disk bomb
Every image, video and file that crosses a room your users are in can end up cached on your disk, including remote media your own users never opened. Default retention in Synapse keeps that indefinitely. The result is predictable and still catches people: a server whose database is stable and whose media directory quietly grows until the volume fills, at which point the symptom is not "disk full" but "the server behaves strangely".
Set a retention policy for remote media on day one rather than after the first outage. Synapse exposes retention settings in homeserver.yaml, plus admin endpoints for purging old history and cached files; synapse-compress-state reclaims a surprising amount from the state tables on an older server. Keep an eye on both the database and the media path, and alert on free space rather than on the service being down — the second symptom arrives days after the first.
One setting deserves a decision rather than a default. URL previews make your server fetch any link posted in a room, which means your server's IP address makes an outbound request to a third party the instant someone pastes a link — including a link chosen specifically to see who bites. If your homeserver sits behind a front and its real address matters, weigh that carefully; our guide on hiding an origin address covers the same class of leak in more detail.
Registration, spam and the reputation you inherit
Open registration on a public homeserver is an invitation, and not the kind you want. Automated signups turn a small server into a spam source inside days, and the consequence is not local: other homeservers add your domain to access-control lists, and once your name is on enough of them your legitimate users stop being able to participate in rooms elsewhere. Recovering a burned domain reputation is far harder than avoiding it, exactly as with mail deliverability.
The defensible defaults are simple. Keep enable_registration off for a private server and hand out accounts yourself. If you want the door open, gate it: registration_requires_token turns registration into an invite system without any third-party service, and a captcha helps against the crude end of the problem. For rooms you administer, moderation bots in the Mjolnir and Draupnir family let you apply ban lists and room ACLs across a whole community rather than one room at a time.
Worth knowing in the other direction: our address ranges are not carried on the Matrix ACL blocklists that circulate between homeservers, so a new server starts from a clean reputation. What happens to that reputation afterwards is set by how you run registration, not by where the machine is.
Bridges, and the metadata bill they come with
Bridges are the honest reason many people stay on Matrix: one client for rooms that live on other networks. They also change your server's security position in a way that is easy to skip past. A bridge holds credentials for the remote account and, at the boundary where protocols meet, it necessarily handles messages in a form it can convert — which means the bridge process sees plaintext for traffic that is end-to-end encrypted on both sides of it.
That is not a reason to avoid bridges. It is a reason to treat the bridge host as sensitive infrastructure: it is the machine that, if compromised, exposes the accounts it speaks for. Each bridge roughly doubles the memory footprint of a small server, so plan capacity accordingly, and give the same thought to where it runs as you gave to the homeserver itself — the reasoning in our jurisdiction guide applies with more force to a box holding several networks' credentials at once.
Keeping it alive: keys, backups and upgrades
A Matrix server has one file whose loss is unrecoverable in a way that has nothing to do with data volume. The signing key — signing.key in Synapse — is how your server proves that events claiming to come from your domain really do. Lose it and you cannot credibly be your own server any more; peers will reject events signed by a stranger holding your name. Back it up separately from everything else, and keep that copy off the machine.
Back up the key and the database, and understand why restoring one without the other is dangerous. Rolling a Matrix database back to an older snapshot puts your server in a state its peers have already moved past, and the resulting divergence is far harder to repair than a clean rebuild. Take consistent dumps with pg_dump, keep them off-box, and remember that on this platform there is no provider copy to fall back on — nothing is retained after termination, which is the whole point of the arrangement and is covered in our backup guide.
Upgrades are ordinary but not optional. Homeserver releases carry schema migrations, and skipping many versions turns a five-minute upgrade into an afternoon. Read release notes before jumping, upgrade regularly enough that each step is small, and do the basic host hygiene from the first-hour hardening checklist — a chat server is a long-lived internet-facing service with a database attached, and it deserves the same treatment as one.
Where the server lives still decides the outcome
Everything above is configuration. The part configuration cannot touch is which legal system receives a request about your users, and for a communications server that question carries more weight than for a website. A homeserver holds membership records, timestamps and social-graph data in the clear even when message bodies are encrypted — so the jurisdiction hosting it is the jurisdiction that governs access to that record.
That is the practical case for choosing a location on purpose rather than by latency alone. We run seven, and the trade-offs between them are set out in the jurisdiction guide and on the locations page. The other half of the same question is who the provider knows you to be: an account with no identity attached cannot produce identity documents it never collected, which is the plain reason no-KYC hosting and self-hosted communications keep appearing in the same conversation. Neither is a defence against a court that already has your name, and our OpSec guide is blunt about where that line sits.
The short version
If you take six things from this page, take these:
- Pick the
server_namebefore installing anything — it is the one decision you can never revise. - Delegate with
/.well-known/matrix/serveror an SRV record, and keep valid TLS on both names. - Size for the rooms your users will join, not for how many users you have.
- Set media retention on day one, and decide about URL previews rather than inheriting the default.
- Keep registration closed or token-gated; a burned domain reputation is expensive to undo.
- Back up
signing.keyseparately, and never roll the database back behind your peers.
Do those and the server will be unremarkable, which is exactly what a chat server should be. What you get in exchange is worth being clear-eyed about: not invisibility, and not a protocol that hides who talks to whom, but conversations whose contents are yours, an account nobody else can close, and a machine sitting under a legal system you chose deliberately. Put a homeserver somewhere you picked, and let the federation come to it.