Best server for Matrix homeserver (Synapse/Dendrite) 2026

For efficient Matrix server operation in 2026, the optimal choice is a VPS with 4 GB of RAM, 2 modern CPU cores (e.g., AMD EPYC or Intel Xeon Gold), and 80 GB of NVMe space — this best vps for matrix synapse configuration ensures stable federation and bridge operation, with an average rental cost of $12–18 per month.

Why choosing the best VPS for Matrix Synapse depends on federation?

Choosing a server for Matrix is fundamentally different from choosing hosting for a regular messenger or website. The main load falls on the RAM and disk subsystem due to the federation mechanism. When your server connects to large rooms (e.g., #matrix:matrix.org), it begins exchanging a huge number of JSON events with thousands of other nodes. This requires the constant presence of the event graph in memory and active database interaction.

If you plan to use a synapse vps for personal communication with 2-3 friends without joining public channels, the requirements will be minimal. However, in the global federation environment of 2026, even an empty server can start consuming resources exponentially when subscribing to active rooms. For this reason, matrix hosting requires a RAM buffer, as the Python implementation of Synapse is prone to memory fragmentation when processing large volumes of incoming data.

It is important to consider that Matrix is not just about messages, but also cryptographic signatures. Every request is verified for authenticity, which creates a load on the CPU. Unlike similar decentralized solutions such as Mastodon, Matrix is more demanding regarding disk latency. If you are looking for the best server for a Mastodon instance 2026, you will notice that Matrix consumes 30-40% more resources for a similar number of active connections.

The impact of room size on resource selection

In Matrix, there are rooms with tens of thousands of participants. When entering such a room, your server must load the history, verify the keys of all participants, and build a local copy of the room state. This causes sharp spikes in RAM consumption (up to 2-3 GB at once). Without sufficient Swap or physical memory, the Synapse process will be terminated by the system OOM Killer.

Synapse VPS characteristics: from RAM to disk subsystem speed

For the best vps for matrix synapse, PostgreSQL database performance is critical. Synapse performs many small read and write operations. Using standard SSDs (SATA) in 2026 is no longer sufficient for a smooth experience. Only NVMe drives provide the necessary IOPS for fast message synchronization.

RAM is the most expensive and important resource. Synapse is written in Python, and although the developers at Element are constantly optimizing memory usage, architectural features dictate their own rules. The minimum threshold for comfortable operation is 4 GB. If you plan to install bridges (e.g., mautrix-whatsapp or mautrix-telegram), add 512 MB - 1 GB for each bridge.

CPU power affects the speed of encryption and media processing. Matrix actively uses end-to-end encryption (E2EE), and while the main load falls on client devices, the server processes metadata and manages keys. For 10-20 users, 2 vCPUs are sufficient, but they should have a high clock speed (2.5 GHz and above).

Optimizing PostgreSQL for Synapse

The database is the heart of your Matrix server. By default, PostgreSQL is not tuned for Synapse's specific needs. On your synapse vps, you need to modify parameters such as shared_buffers, work_mem, and effective_cache_size. For example, for a server with 4 GB of RAM, it is recommended to allocate 1 GB to shared_buffers. This will significantly speed up message history searches and reduce CPU load.

# Example of basic postgresql.conf optimization for 4GB RAM
max_connections = 100
shared_buffers = 1024MB
effective_cache_size = 3072MB
maintenance_work_mem = 256MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 10MB
min_wal_size = 1GB
max_wal_size = 4GB

Dendrite VPS: how realistic is it to save on resources in 2026?

Dendrite is a second-generation Matrix implementation written in Go. Unlike Synapse, a dendrite vps consumes significantly less memory and scales better. In 2026, Dendrite has already moved out of deep beta and is suitable for many use cases where support for every single experimental feature (MSC) is not required.

The main advantage of Dendrite is "out of the box" multi-threading and a low RAM entry threshold. While Synapse requires 4 GB for normal operation, Dendrite can run stably on 2 GB even with active federation. This makes it an ideal choice for those who want to deploy their own node on budget hardware.

However, it is worth noting that the ecosystem of bridges and additional services is still better optimized for Synapse. If your goal is integration with all possible messengers, Synapse remains the standard. If you need a fast and lightweight server for the pure Matrix protocol, Dendrite is the favorite. To ensure privacy and traffic filtering on such a server, additional tools are often used, which you can read about in the article on the best server for Pi-hole + Unbound + AdGuard 2026.

Synapse vs Dendrite comparison in numbers

• Idle RAM consumption: Synapse (~500MB) vs Dendrite (~150MB).
• Development language: Python (Synapse) vs Go (Dendrite).
• Configuration complexity: Synapse has more documentation; Dendrite has a simpler configuration file.
• Performance: Dendrite shows 40% lower latency when processing client-server requests (C-S API).

Matrix hosting and media content management: S3 vs local storage

One of the main problems when operating Matrix is the uncontrolled growth of the media folder. Users exchange images, videos, and files that are cached on your server from other instances. Over a year of active use, the database can grow to 20 GB, and the media storage to 200 GB or more.

When choosing matrix hosting, ensure the provider allows for easy disk space expansion or the connection of external block storage. In 2026, the de facto standard for large instances is using S3-compatible storage to offload the media repository. This allows the VPS itself to remain compact and fast, using cheap object storage for heavy data.

To ensure the safety of this data, it is critical to set up regular backups. We recommend checking the guide on choosing the best server for a self-hosted backup target 2026, so your Matrix instance doesn't turn into a pile of useless data after a disk failure.

Cache cleanup strategies

To avoid overpaying for disks on a synapse vps, you must configure automatic cleanup of the remote media cache. In the Synapse configuration, you can set a lifetime for files received from federation:

# In homeserver.yaml
media_retention:
  local_media_lifetime: 1y
  remote_media_lifetime: 30d

This will automatically delete old images from other people's rooms, saving tens of gigabytes of space without harming the user experience (the file will simply be re-downloaded upon the next request).

Performance Optimization: Workers and Caching

When your server grows beyond 50 active users, a standard single-process Synapse setup stops coping. The Python GIL (Global Interpreter Lock) limits CPU usage. The solution is to move Synapse to a worker architecture.

Workers allow you to split tasks: one process handles message reception, another handles federation, and a third handles media files. This requires setting up Redis as a data exchange bus between processes. For such a configuration, the best vps for matrix synapse should have at least 4 cores, as each worker is a separate process consuming RAM.

Using Redis is not only necessary for workers but also significantly speeds up request caching. In 2026, even small instances benefit from Redis, as it reduces the number of direct queries to PostgreSQL. For large-scale Matrix deployments in containers, it is useful to study information about the best server for a Kubernetes cluster 2026, as Matrix is highly orchestratable.

Example of worker separation in Docker Compose

services:
  synapse:
    image: matrixdotorg/synapse:latest
    # Main process for C-S API
  
  federation_sender:
    image: matrixdotorg/synapse:latest
    command: ["python", "-m", "synapse.app.federation_sender"]
    # Worker for sending events to federation
    
  media_repository:
    image: matrixdotorg/synapse:latest
    command: ["python", "-m", "synapse.app.media_repository"]
    # Worker for handling files

Technical comparison of plans for different tasks

When choosing a provider for matrix hosting, you need to look not only at the price but also at the virtualization type (KVM is mandatory) and the quality of network channels. Matrix federation is sensitive to packet loss. If your server is in Europe and most of your contacts are in the US, latency can slow down room synchronization.

In 2026, the market offers three main VPS rental scenarios for Matrix:

When choosing a synapse vps, avoid offers with OpenVZ virtualization. Matrix requires deep kernel tuning (e.g., for open file limits or memory management), which is often restricted in container-based virtualization. Only KVM guarantees you dedicated resources that won't be "stolen" by neighbors on the node during peak loads.

Security and resilience of a Matrix instance

Running your own Matrix server carries responsibility for the safety of encryption keys. If you lose the database or server keys (signing keys), you will permanently lose access to encrypted rooms and will not be able to restore communication with other servers in the federation under the same domain name.

Recommendations for protecting matrix hosting:

1. Use a Reverse Proxy: Always put Nginx or Caddy in front of Synapse. This allows for easy SSL certificate management (Let's Encrypt) and protection against basic DDoS attacks.
2. Bridge Isolation: Run bridges in separate Docker containers with limited privileges.
3. Firewall: Close all ports except 80, 443, and 8448 (federation port).
4. Monitoring: Use a Prometheus + Grafana stack. Synapse has a built-in metrics endpoint, allowing you to see memory leaks or abnormal federation queue growth in real-time.

For those who want maximum security, consider moving the database to a separate protected server, a practice used in high-load systems.

Conclusions

To launch a reliable Matrix server in 2026, choose a VPS with 4 GB of RAM and an NVMe disk, preferring Synapse for maximum bridge compatibility or Dendrite for resource savings. Be sure to tune PostgreSQL and use S3 storage for media files to ensure long-term scalability and federation stability.