Self-Hosted Matrix or XMPP on a No-KYC VPS: Sizing, Federation and Metadata Limits

If you want a private chat server you actually control, the short answer is: an XMPP server (Prosody or ejabberd) runs comfortably on the smallest VPS tier — 1 vCPU and 1 GB RAM is genuinely enough for a handful of users. A Matrix homeserver is a different animal: Synapse with PostgreSQL wants 2–4 GB of RAM in practice, and the moment you join large federated rooms, CPU and memory use climbs hard. Lighter Matrix implementations exist, and they change the sizing math considerably.

This guide covers what each option actually needs, how disk and bandwidth grow over time, and — just as important — what running your own chat server does and does not hide.

XMPP vs. Matrix: pick before you pick a plan

These two protocols solve the same problem with very different resource profiles.

XMPP (Prosody, ejabberd) is lean by design. A small Prosody instance with a dozen accounts, multi-user chat rooms and HTTP file upload typically sits in the tens to low hundreds of megabytes of RAM. End-to-end encryption comes from OMEMO, supported by Conversations, Gajim, Monal and others. The trade-off is client inconsistency — feature support varies between apps, and onboarding non-technical users takes more hand-holding.

Matrix (Synapse) is far more polished on the client side thanks to Element, with device verification, E2EE by default in private rooms and solid mobile apps. The cost is weight. Synapse is a Python application that should run against PostgreSQL rather than SQLite for anything beyond a toy install, and its memory footprint is driven less by your user count than by the number and size of federated rooms your users join. Matrix room state resolution is computationally expensive; a single user joining a very large public room can push a small homeserver into swap.

Lighter Matrix servers — Conduit and its forks (Rust, embedded database) and Dendrite (Go) — use substantially less RAM than Synapse because they avoid the Python runtime and heavy caching layers. They are not feature-complete with Synapse, so check that what you need (spaces, specific admin APIs, appservice bridges) is supported before committing.

Realistic plan sizing

Mapping that to IronBalkans' KVM plans, where vCPU, RAM and NVMe are dedicated rather than shared out across an oversold node:

• Iron 1 (1 vCPU, 1 GB RAM, 15 GB NVMe, 1 TB) — fine for Prosody or ejabberd serving a family, a small team or a project group. Also workable for a Conduit-style Matrix homeserver with a small, disciplined user base. Tight but viable for Synapse only if you keep federation minimal, avoid huge public rooms and tune caches down.
• Iron 2 (2 vCPU, 4 GB RAM, 35 GB NVMe, 4 TB) — the sensible starting point for Synapse + PostgreSQL + nginx + coturn. This is the plan most people self-hosting Matrix for a small community should pick.
• Iron 3 (4 vCPU, 8 GB RAM, 70 GB NVMe, 8 TB) — for a Matrix server whose users live in large federated rooms, or where you also run bridges (Signal, Telegram, IRC), which each add their own database and process overhead.
• Iron 4 (8 vCPU, 16 GB RAM, 130 GB NVMe, 16 TB) — relevant mainly if you're hosting a real community, running multiple bridges, or combining chat with other services.

If you want the broader comparison across workloads, the no-KYC VPS plan sizing guide covers how RAM, NVMe and bandwidth map to other project types.

A note on the smallest tier: a 1 GB server running a database plus an application server needs swap configured properly, or the kernel's OOM killer will eventually pick the wrong process. The practical steps for that are in the low-RAM VPS tuning guide.

Disk and bandwidth: the part people underestimate

RAM is the headline constraint, but disk is what quietly kills small chat servers.

Matrix homeservers cache remote media — every image, video and file posted in any room your users join gets pulled to your disk. Without a retention policy, 15 GB disappears faster than you'd expect. Set media retention limits (for Synapse, media_retention with local and remote lifetimes), cap max_upload_size, and run periodic purges of old room history where appropriate. The state database also grows; Synapse's state compressor tooling exists for a reason.

XMPP is gentler: message archive management (MAM) storage is text, and file uploads are governed by mod_http_upload quotas you set yourself.

Bandwidth is usually not the binding constraint — text chat and federation traffic are small. The exception is voice and video calls. Matrix calls use WebRTC, and when peers can't connect directly, media gets relayed through a TURN server (coturn) running on your VPS. Relayed calls consume real bandwidth in both directions, roughly 100–200 kbps per participant stream for audio, far more for video. On a 4 TB monthly allowance that's still comfortable for a small group, but it's worth measuring with vnstat rather than guessing.

What federation actually requires from your server

Matrix federation is where hosting requirements get specific, and where a cheap NAT-only VPS falls apart:

• A dedicated IPv4 address, not a shared or port-mapped one. Federation and TURN both need inbound ports you control.
• A domain and working DNS, including either port 8448 open for federation or a /.well-known/matrix/server delegation served over 443.
• Valid TLS certificates for both the client-facing and federation endpoints. Let's Encrypt handles this fine.
• Open UDP port ranges for coturn if you want reliable calls.
• Closed or token-gated registration. An open Matrix homeserver becomes a spam relay within days, which generates abuse reports against your IP.

Every IronBalkans plan includes a dedicated IPv4 plus a /64 IPv6 block and DDoS filtering, which covers the network side of that list. The parts you own are the software, the TLS, the registration policy and the backups.

Here's where the hosting choice intersects with the privacy goal: signing up for a chat server's hosting usually means handing a company your name, email and card details — which then sit in a billing database alongside the IP of the server hosting your private conversations. IronBalkans accounts need no email, name, phone or ID; you get a random account ID and a recovery key, pay in Monero, Bitcoin or Litecoin, and the server is live in under a minute. That removes the billing identity from the equation. It does not remove the other identity trails, which is the next section.

What your own chat server does not hide

This matters more than the sizing numbers, because people self-host chat expecting a privacy outcome the architecture can't deliver on its own.

Your homeserver sees all metadata. End-to-end encryption in Matrix (Olm/Megolm) and OMEMO in XMPP protects message content from the server operator. It does not hide room membership, display names, timestamps, device lists, read receipts, or who talks to whom and how often. If you run the server, you hold that metadata — which is better than a third party holding it, but it's still a database that exists on a disk you need to protect.

Federation broadcasts to other servers. Every remote homeserver your users federate with learns your server name, your users' IDs in shared rooms, and activity timing. Federation is a feature, not a privacy boundary.

Your domain is an identity. A homeserver's name is visible to everyone it talks to. If that domain is registered with your real name and public WHOIS data, the crypto payment for the VPS bought you very little. Handle the domain layer deliberately — see anonymous domain registration and private DNS for the specifics on WHOIS, DNS hosting and Certificate Transparency exposure.

Push notifications can leak. Mobile push for Matrix typically routes through a push gateway and then Google or Apple infrastructure. Even with encrypted event payloads, the fact that a notification was delivered to a device is observable. Self-hosting a gateway (sygnal) helps; using an app with native background connections helps more.

You are the anonymity set. A commercial messenger hides you among millions of users. A personal homeserver with eight accounts does not. If your threat model is traffic analysis by a well-resourced adversary, self-hosting shifts control to you but shrinks the crowd you blend into.

Backups are not optional here

A chat server is the kind of service where data loss is unforgivable, and there are two things to back up beyond the obvious database:

1. The server signing key. Lose Synapse's signing key and your homeserver's federation identity is gone — remote servers will reject your events. Back it up separately from the database.
2. The media store. Database dumps alone restore text, not attachments.

Dump PostgreSQL properly (pg_dump, not a file copy of a running data directory), include the media directory and config, and push it off the server encrypted. The workflow — repository layout, retention, and actually testing restores — is covered in the encrypted off-site VPS backups guide.

Common mistakes

• Running Synapse on SQLite because the quickstart allowed it, then discovering it doesn't scale and migration is painful.
• Leaving registration open, attracting spam accounts and abuse complaints against your IP.
• No media retention policy, so the disk fills with cached images from rooms nobody reads anymore.
• Joining a massive public room on a 1 GB server and wondering why everything stalls.
• Treating E2EE as metadata protection. It isn't.
• Buying the smallest plan for Matrix because the docs listed low minimums. Minimums assume an idle, unfederated server.

FAQ

Can one VPS run both Matrix and a website? Yes, behind a single reverse proxy, provided you have the RAM headroom — Iron 2 or above. Whether you should combine them is a separate question about isolation and blast radius.

Which is cheaper to run long-term, Matrix or XMPP? XMPP, clearly. It fits on the €4.99/mo tier and stays there. Matrix buys you better clients and bridges at roughly double the hosting cost.

Do I need port 25 or email for registration? No. You can run invite-token or admin-created accounts and skip email verification entirely, which also keeps your users' addresses out of your database.

Does Bucharest hosting add noticeable latency for chat? For text, no — chat is not latency-sensitive at the tens-of-milliseconds scale. For relayed voice calls, European users will be fine; participants on other continents will notice.

Getting started

If you've settled on XMPP for a small group, the entry tier is enough. If you want Matrix with federation and bridges, start at Iron 2 (2 vCPU, 4 GB RAM) and plan a media retention policy on day one. Either way, you can spin the server up with no email, no ID and a crypto payment, and have root access in under a minute: review the plans and deploy.