[Home](https://servhidden.com/) /
[Privacy Hosting Guides](https://servhidden.com/guides) /
Self-Hosting Matrix: Federation, Metadata and What E2EE Doesn’t Hide






Operations


# Self-Hosting a Matrix Server



A homeserver is not a private box that speaks chat — it is a replication node in a public network. What self-hosting Matrix genuinely fixes, what end-to-end encryption leaves in the clear, which implementation to run, and the operational decisions that are irreversible.


[Read the guide](#guide-body)
[FAQ](#guide-faq)






## On this page




- [Guide](#guide-body)

- [FAQ](#guide-faq)

- [Related guides](#guide-related)

- [Recommended pages](#guide-cta)






No KYC
Crypto Only
No Logs
DMCA Ignored
Full Root
NVMe SSD





16 min read
Updated Aug 2026

On this page

[01What running your own homeserver actually changes](#what-running-your-own-homeserver-actually-changes)
[02Federation is a replication protocol wearing a chat protocol's clothes](#federation-is-a-replication-protocol-wearing-a-chat-protocol)
[03What encryption covers, and what stays in the clear](#what-encryption-covers-and-what-stays-in-the-clear)
[04Synapse, Dendrite or Conduit — what to actually run](#synapse-dendrite-or-conduit-what-to-actually-run)
[05The delegation setup everyone gets wrong](#the-delegation-setup-everyone-gets-wrong)
[06Sizing it honestly](#sizing-it-honestly)
[07The media store is a slow-motion disk bomb](#the-media-store-is-a-slow-motion-disk-bomb)
[08Registration, spam and the reputation you inherit](#registration-spam-and-the-reputation-you-inherit)
[09Bridges, and the metadata bill they come with](#bridges-and-the-metadata-bill-they-come-with)
[10Keeping it alive: keys, backups and upgrades](#keeping-it-alive-keys-backups-and-upgrades)
[11Where the server lives still decides the outcome](#where-the-server-lives-still-decides-the-outcome)
[12The short version](#the-short-version)
[FAQCommon questions](#guide-faq)
[→Recommended pages](#guide-cta)







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](https://servhidden.com/guides/how-to-host-a-tor-hidden-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.

A homeserver is a participant in a public network, not a private box: every server with a member in your room keeps its own copy of who joined, when, and how often they speak.

## 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 conduwuit are 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](https://servhidden.com/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](https://servhidden.com/use-cases/matrix-xmpp-hosting) 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](https://servhidden.com/guides/hiding-your-origin-server-ip) 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](https://servhidden.com/guides/offshore-mail-server-setup).

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](https://servhidden.com/guides/choosing-an-offshore-jurisdiction) 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](https://servhidden.com/guides/vps-backup-strategy).

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](https://servhidden.com/guides/first-hour-vps-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](https://servhidden.com/guides/choosing-an-offshore-jurisdiction) and on the [locations page](https://servhidden.com/locations). 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](https://servhidden.com/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](https://servhidden.com/guides/server-opsec-staying-anonymous) is blunt about where that line sits.

## The short version

If you take six things from this page, take these:

- Pick the server_name before installing anything — it is the one decision you can never revise.

- Delegate with /.well-known/matrix/server or 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.key separately, 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](https://servhidden.com/use-cases/matrix-xmpp-hosting), and let the federation come to it.





FAQ

## Self-hosted Matrix — common questions





### 01
Does self-hosting Matrix make my messages more private?



It changes custody rather than cryptography. Message contents in private rooms are already end-to-end encrypted before they reach any server, including a commercial one, so self-hosting does not encrypt anything that was not already encrypted. What it changes is who holds the metadata, who can close your account, and which legal system receives a request about it. Those are real gains, but they are different gains from the one people usually assume.





### 02
Can the admins of other homeservers read my rooms?



They cannot read the contents of encrypted messages, and they can see a great deal else. Any homeserver with a user in your room receives and stores the room state: who is a member, when people joined or left, display names, timestamps, reactions and the size and timing of file transfers. That data lives in their database on their terms, and deleting it on your side does not remove it from theirs.





### 03
Synapse or Conduit — which should I run?



Conduit or conduwuit for a small private server, because a single Rust binary with an embedded database runs happily on an entry-level plan and needs very little attention. Synapse for anything you expect to grow, run bridges on, or moderate publicly, because it is the reference implementation and every feature and admin tool targets it first. Migrating between implementations later means exporting and rebuilding, so choose with the second year in mind.





### 04
How much RAM does a Matrix server need?



For Synapse, about 2 GB to start, roughly 4 GB for ten to fifty active users, and 8 GB or more beyond a hundred. Conduit-family servers run well below those figures. The important correction is that memory tracks the number and size of the rooms your users join rather than the number of accounts you host — a few users in many large public rooms cost more than many users in small private ones.





### 05
Why does my homeserver use so much disk?



Two causes, usually together. Joining large federated rooms pulls other servers history and state onto your disk, so a small server can carry a large database honestly. And remote media is cached indefinitely by default, so images and files from rooms your users are merely present in accumulate forever. Set a retention policy for remote media early, purge old history periodically, and monitor free space rather than waiting for symptoms.





### 06
Should I leave registration open?



Not on a server you care about. Open registration attracts automated signups that turn your domain into a spam source, and other homeservers respond by adding it to shared access-control lists — at which point your legitimate users are blocked from rooms elsewhere. Keep registration disabled and create accounts yourself, or gate it behind registration tokens so the door opens only for people you invited.





### 07
Does running a bridge break end-to-end encryption?



It moves the boundary. A bridge has to convert between two protocols, so at that point it necessarily handles messages in readable form and it holds credentials for the remote account. Traffic stays encrypted on the Matrix side and on the other network, but the bridge itself is a place where both are legible. Treat the machine running it as sensitive infrastructure, and note that each bridge roughly doubles the memory footprint of a small server.





### 08
Can I change my server_name later?



No, and this is worth reading twice before you install. The server_name is baked into every user ID, room ID and signed event your server produces, so changing it means abandoning the accounts and rooms rather than renaming them. Choose the bare domain you actually want, then use .well-known delegation or an SRV record to point it at whichever host runs the software.




Related guides

## Keep reading


[### How to Choose an Offshore Hosting Jurisdiction in 2026

Buying


A practical decision framework for picking an offshore jurisdiction: data-retention law, MLAT exposure, DMCA stance, court speed and real-world enforcement — country by country.


6-question FAQ](https://servhidden.com/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Dedicated Server for Privacy-Critical Workloads

Buying


When a VPS is fine, when shared tenancy is a liability, and when bare metal is the only honest answer. Hardware isolation, hypervisor risk, and cost vs threat model.


6-question FAQ](https://servhidden.com/guides/vps-vs-dedicated-for-privacy)
[### Self-Hosted VPN on a No-KYC VPS: WireGuard vs OpenVPN

Operations


Why a self-hosted VPN beats commercial providers, and how WireGuard and OpenVPN really compare on privacy, performance and operational risk in 2026.


6-question FAQ](https://servhidden.com/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 for AI Inference (and Where the RTX 5090 Fits)

Buying


Buying guide: which NVIDIA GPU for self-hosted LLM, image, video, speech, and fine-tuning workloads in 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, when each wins.


6-question FAQ](https://servhidden.com/guides/rtx-4090-vs-h100-for-ai-inference)
[### Offshore Windows RDP for MT4 / MT5 / cTrader Forex Trading

Operations


Complete guide: why a Windows RDP for Forex trading, how to choose a low-latency offshore jurisdiction, MT4 / MT5 / cTrader / Expert Advisor setup, latency to broker servers, and the no-KYC checkout path.


6-question FAQ](https://servhidden.com/guides/offshore-windows-rdp-for-forex-trading)
[### DMCA-Ignored Hosting Explained: What It Really Means in 2026

Buying


What "DMCA ignored" hosting genuinely buys you, which jurisdictions actually back it up, the workloads that need it, and the copyright traps the term doesn't cover.


6-question FAQ](https://servhidden.com/guides/dmca-ignored-hosting-explained)
[### Anonymous Domain Registration with Crypto: WHOIS Privacy in 2026

Privacy


A practical 2026 guide to registering domains without revealing your identity: WHOIS regimes by TLD, registrar choice, crypto payment options, and the operational mistakes that leak you anyway.


6-question FAQ](https://servhidden.com/guides/anonymous-domain-registration-with-crypto)
[### Crypto Payments for Hosting: Monero vs Bitcoin vs USDT

Privacy


How payment coin affects what your host learns about you. Privacy, fees, finality and chain analysis exposure for XMR, BTC and USDT — with a clear recommendation.


6-question FAQ](https://servhidden.com/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Is Offshore Hosting Truly Anonymous? An Honest Answer

Privacy


Offshore, no-KYC hosting removes the identity a normal host collects — but "anonymous" depends on payment, provider logging and your own opsec. Here is what is really traceable.


6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-truly-anonymous)
[### The First Hour of VPS Hardening: A Checklist

Operations


A concrete, ordered checklist to secure a new VPS in under an hour: SSH keys, a firewall, fail2ban, automatic updates, and the attack-surface reduction that stops most opportunistic attacks.


6-question FAQ](https://servhidden.com/guides/first-hour-vps-hardening-checklist)
[### What Is No-KYC Hosting? Definition, Legality & How It Works

Privacy


No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider.


6-question FAQ](https://servhidden.com/guides/what-is-no-kyc-hosting)
[### Is Offshore Hosting Legal? The Honest 2026 Answer

Buying


Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly.


6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-legal)
[### How to Pay for Hosting with Monero (XMR) — Step by Step

Privacy


A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes.


6-question FAQ](https://servhidden.com/guides/how-to-pay-for-hosting-with-monero)
[### How to Host a Website Anonymously — A Practical 2026 Guide

Privacy


A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained.


6-question FAQ](https://servhidden.com/guides/how-to-host-a-website-anonymously)
[### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide

Operations


Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it.


6-question FAQ](https://servhidden.com/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### How to Self-Host an LLM on a GPU Server — 2026 Guide

Operations


Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs.


6-question FAQ](https://servhidden.com/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting vs Offshore Hosting — What Is the Difference?

Buying


Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want.


6-question FAQ](https://servhidden.com/guides/bulletproof-vs-offshore-hosting)
[### How to Buy a VPS with Bitcoin — Step-by-Step (2026)

Buying


A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached.


6-question FAQ](https://servhidden.com/guides/how-to-buy-a-vps-with-bitcoin)
[### Best Countries for DMCA-Ignored Hosting in 2026

Buying


Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose.


6-question FAQ](https://servhidden.com/guides/best-countries-for-dmca-ignored-hosting)
[### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide

Operations


Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous.


6-question FAQ](https://servhidden.com/guides/how-to-host-a-tor-hidden-service)
[### Offshore Mail Server Setup — Self-Host Private Email in 2026

Operations


Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right.


6-question FAQ](https://servhidden.com/guides/offshore-mail-server-setup)
[### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS

Operations


How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private.


6-question FAQ](https://servhidden.com/guides/crypto-node-hosting-guide)
[### GPU Hosting for Stable Diffusion — Run Your Own Image Server

Operations


Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service.


6-question FAQ](https://servhidden.com/guides/gpu-hosting-for-stable-diffusion)
[### Server OpSec — Staying Anonymous When You Run a Server

Privacy


Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate.


6-question FAQ](https://servhidden.com/guides/server-opsec-staying-anonymous)
[### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026

Operations


How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure.


6-question FAQ](https://servhidden.com/guides/seedbox-setup-guide)
[### How to Bypass DPI Censorship with Your Own VPS (2026 Guide)

Privacy


Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough.


6-question FAQ](https://servhidden.com/guides/bypass-dpi-censorship-with-your-own-vps)
[### Full-Disk Encryption on a VPS: LUKS Setup and What It Really Protects

Operations


How to encrypt a VPS with LUKS: encrypted data volumes, full-root encryption with remote unlock over SSH, the settings that matter on a small server, and an honest account of what disk encryption stops.


8-question FAQ](https://servhidden.com/guides/full-disk-encryption-on-a-vps)
[### Hiding Your Origin Server IP: CDNs, Reverse Proxies and What Still Leaks

Privacy


Whether to put a CDN in front of an offshore server: what it hides, the abuse desk you inherit, the six ways an origin IP leaks anyway, and how to audit yours.


8-question FAQ](https://servhidden.com/guides/hiding-your-origin-server-ip)
[### VPS Backup Strategy: Encrypted, Off-Site and Actually Restorable

Operations


Your host keeps no backups. What really destroys servers, why push backups die with them, restic vs Borg, the keys everyone forgets, and how to test a restore.


8-question FAQ](https://servhidden.com/guides/vps-backup-strategy)
[### How to Migrate a Website to Offshore Hosting Without Downtime

Operations


The order that makes a host migration boring: lower the DNS TTL days ahead, run both servers in parallel, freeze writes for minutes rather than hours — and clean up the passive-DNS, Certificate Transparency and WHOIS trail the move leaves behind.


8-question FAQ](https://servhidden.com/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operations


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


8-question FAQ](https://servhidden.com/guides/self-host-a-crypto-payment-gateway)




## Run the homeserver where you chose



Seven jurisdictions, full root, custom ISO and unmetered bandwidth on every plan — from $7.50/mo for a small Conduit or Dendrite server. No KYC, no email, crypto only.


[View VPS Plans](https://servhidden.com/vps)
[All Locations](https://servhidden.com/locations)
[Private Hosting](https://servhidden.com/anonymous-hosting)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "Offshore VPS & dedicated servers in 7 offshore jurisdictions. No KYC, no logs, crypto only. Privacy by architecture.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Self-Hosting Matrix: Federation, Metadata and What E2EE Doesn’t Hide",
    "description": "What a Matrix homeserver really gives you: Synapse vs Conduit, the server_name you can never change, media that eats the disk, and what federation still reveals.",
    "image": "https://servhidden.com/assets/img/guides/self-host-a-matrix-server.webp?v=1787253905",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-21T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/self-host-a-matrix-server",
    "inLanguage": "en",
    "keywords": "self-host Matrix server, Matrix homeserver setup, Synapse vs Conduit, Matrix server_name delegation, Matrix federation privacy, Matrix media retention, private chat server hosting, Matrix homeserver RAM requirements",
    "articleSection": "Operations",
    "wordCount": 3062
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "Does self-hosting Matrix make my messages more private?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "It changes custody rather than cryptography. Message contents in private rooms are already end-to-end encrypted before they reach any server, including a commercial one, so self-hosting does not encrypt anything that was not already encrypted. What it changes is who holds the metadata, who can close your account, and which legal system receives a request about it. Those are real gains, but they are different gains from the one people usually assume."
            }
        },
        {
            "@type": "Question",
            "name": "Can the admins of other homeservers read my rooms?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "They cannot read the contents of encrypted messages, and they can see a great deal else. Any homeserver with a user in your room receives and stores the room state: who is a member, when people joined or left, display names, timestamps, reactions and the size and timing of file transfers. That data lives in their database on their terms, and deleting it on your side does not remove it from theirs."
            }
        },
        {
            "@type": "Question",
            "name": "Synapse or Conduit — which should I run?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Conduit or conduwuit for a small private server, because a single Rust binary with an embedded database runs happily on an entry-level plan and needs very little attention. Synapse for anything you expect to grow, run bridges on, or moderate publicly, because it is the reference implementation and every feature and admin tool targets it first. Migrating between implementations later means exporting and rebuilding, so choose with the second year in mind."
            }
        },
        {
            "@type": "Question",
            "name": "How much RAM does a Matrix server need?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "For Synapse, about 2 GB to start, roughly 4 GB for ten to fifty active users, and 8 GB or more beyond a hundred. Conduit-family servers run well below those figures. The important correction is that memory tracks the number and size of the rooms your users join rather than the number of accounts you host — a few users in many large public rooms cost more than many users in small private ones."
            }
        },
        {
            "@type": "Question",
            "name": "Why does my homeserver use so much disk?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Two causes, usually together. Joining large federated rooms pulls other servers history and state onto your disk, so a small server can carry a large database honestly. And remote media is cached indefinitely by default, so images and files from rooms your users are merely present in accumulate forever. Set a retention policy for remote media early, purge old history periodically, and monitor free space rather than waiting for symptoms."
            }
        },
        {
            "@type": "Question",
            "name": "Should I leave registration open?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Not on a server you care about. Open registration attracts automated signups that turn your domain into a spam source, and other homeservers respond by adding it to shared access-control lists — at which point your legitimate users are blocked from rooms elsewhere. Keep registration disabled and create accounts yourself, or gate it behind registration tokens so the door opens only for people you invited."
            }
        },
        {
            "@type": "Question",
            "name": "Does running a bridge break end-to-end encryption?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "It moves the boundary. A bridge has to convert between two protocols, so at that point it necessarily handles messages in readable form and it holds credentials for the remote account. Traffic stays encrypted on the Matrix side and on the other network, but the bridge itself is a place where both are legible. Treat the machine running it as sensitive infrastructure, and note that each bridge roughly doubles the memory footprint of a small server."
            }
        },
        {
            "@type": "Question",
            "name": "Can I change my server_name later?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No, and this is worth reading twice before you install. The server_name is baked into every user ID, room ID and signed event your server produces, so changing it means abandoning the accounts and rooms rather than renaming them. Choose the bare domain you actually want, then use .well-known delegation or an SRV record to point it at whichever host runs the software."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Home",
            "item": "https://servhidden.com/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Privacy Hosting Guides",
            "item": "https://servhidden.com/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Self-Hosting Matrix: Federation, Metadata and What E2EE Doesn’t Hide",
            "item": "https://servhidden.com/guides/self-host-a-matrix-server"
        }
    ]
}
```

