VPS for Self-Hosted Matrix Server

Matrix is not a single server - it is a federated network where thousands of homeservers communicate using a shared open protocol (similar to email's SMTP federation). When you host your own homeserver, your users get addresses like @user:yourdomain.com. You control the user database, the message history, and the encryption keys. Other Matrix users anywhere on the network can still message your users and join your rooms.

Federation means your server is resilient. If matrix.org has an outage, your homeserver and its rooms continue operating. Your messages are not stored on any other company's servers unless you join rooms hosted elsewhere (in which case only the messages exchanged in that room are replicated to the room's servers - not your private messages). This is fundamentally different from centralized apps where all data passes through one company's infrastructure.

Synapse is the reference homeserver implementation in Python, mature and feature-complete. Dendrite is the newer Go implementation, lighter on resources and better suited for small deployments. For a personal or small-team homeserver, Dendrite is recommended. For a larger organization with many users, Synapse with PostgreSQL and worker processes is the production-proven choice.

Synapse (Python) is memory-heavy and scales poorly below 2 GB RAM. For a homeserver with 1-10 users and minimal federation: 2 vCPU, 2 GB RAM, and a PostgreSQL database. The default SQLite backend is not suitable for production use - switch to PostgreSQL immediately. Synapse's memory usage grows with the number of joined rooms and federation traffic, easily reaching 1-2 GB on a busy server.

Dendrite (Go) is far more efficient. A personal Dendrite homeserver runs comfortably on 512 MB RAM and 1 vCPU. It supports PostgreSQL and SQLite (SQLite is acceptable for very small deployments). Dendrite's federation support has reached near-feature-parity with Synapse and is the recommended choice for new deployments on AnubizHost VPS plans starting at $17.90/mo.

Storage requirements depend on media uploads. Text messages consume negligible space. Images, videos, and file transfers stored in your media repo can accumulate quickly. Start with 20 GB and monitor - you can expand the disk or archive old media. Enable media retention policies in your homeserver config to automatically purge old media and control disk usage.

Matrix requires a valid domain name with HTTPS for federation to work. Register a domain (or use a subdomain of an existing domain), point it at your VPS IP, and obtain an SSL certificate. Install Dendrite from the official GitHub releases: download the pre-built binary for linux/amd64, create a system user, and write a systemd service file. Generate a signing key: ./generate-keys --private-key matrix_key.pem.

Configure dendrite.yaml with your server name (the Matrix domain), PostgreSQL connection string, and media storage path. Set up Nginx as a reverse proxy on port 443 that forwards Matrix federation traffic (port 8448) and client-server API traffic (port 8008) to Dendrite's internal listeners. The .well-known/matrix/server delegation file allows you to run Matrix on a subdomain (e.g., matrix.yourdomain.com) while your Matrix IDs use the root domain (@user:yourdomain.com).

Create your first admin account: ./create-account --config dendrite.yaml --username admin --password . Log in with Element (the official Matrix client) at app.element.io or self-host Element Web on the same VPS. From there, create rooms, invite users, and enable end-to-end encryption on private rooms by default.

One of Matrix's most powerful features is bridging to other messaging networks. The mautrix family of bridges allows your Matrix homeserver to send and receive messages on WhatsApp, Signal, Telegram, Discord, and more. Bridges run as separate bot processes that connect to your homeserver via the Application Service API. Install them on the same VPS (if resources allow) or on a separate VPS instance.

To restrict federation to trusted servers only (useful for corporate or high-security deployments), configure the federation_whitelist in your homeserver config. This prevents your server from federating with arbitrary public Matrix rooms while still allowing selected external servers. Combined with user registration limited to invite-only mode, this creates a private Matrix network accessible only to people you explicitly invite.

AnubizHost's Iceland and Romania nodes both have static IP addresses and low-latency upstream routes to European internet exchanges, which matters for Matrix federation performance. Federation involves many small HTTPS requests between servers - latency, not bandwidth, is the limiting factor. Choose the datacenter closest to where your expected federated servers are located for best federation responsiveness.