SimpleX Chat

Private messenger without any user identifiers

Chat & Communication ★ 19.5k stars Medium setup AGPL-3.0

SimpleX Chat is a privacy-focused messaging platform that has no user profiles or identifiers, routing messages through self-hostable relay servers. Users can run their own SMP relay servers for full control.

Key features

  • No user identifiers at all
  • Self-hostable SMP relay servers
  • End-to-end encryption
  • Decentralized message routing

Pros & cons

Strengths

  • Best-in-class metadata privacy
  • Run your own relays

Trade-offs

  • Newer protocol
  • Group features still maturing

SimpleX Chat replaces

Last reviewed Aug 26, 2026 · 869 words

Self-hosting SimpleX Chat does not mean hosting your account, because there is no account to host. There are no usernames, phone numbers or persistent identifiers anywhere in the protocol; what a server sees is a set of one-directional message queues with random IDs. What you can run is the relay servers those queues live on: an SMP server for messages and an XFTP server for files. Your contacts keep using whichever relays they chose, and the conversation still works, because each side's incoming queues sit on the servers that side picked. That makes SimpleX the rare messenger where self-hosting is optional, incremental and mostly about who gets to see your IP address and traffic timing.

What a relay can and cannot see

Message content is end-to-end encrypted with double ratchet plus post-quantum key agreement, so a relay learns nothing about what you said. What it can observe is metadata: when a queue received a message, its size, and the connecting IP unless the client is using Tor or private message routing, which sends through a second relay so the recipient's server never sees the sender's address. Running your own relay therefore moves that residual metadata from the project's preset operators to you. It is a real gain for people whose threat model includes "who I talk to and when", and close to zero gain for someone who mainly wants messages Meta cannot read, which the default servers already provide. The threat-modeling piece is the honest starting point before you spend a weekend on this.

Two small containers, one public port each

Both servers are Haskell binaries with a Docker image apiece, and the 256 MB figure is generous for a personal relay. The SMP server listens on 5223 by default (443 is also supported so it survives restrictive networks), and XFTP conventionally uses 443 of its own, which means either two IP addresses, two hostnames on different ports, or an accepted compromise:

docker run -d --name smp-server \
  -p 5223:5223 \
  -v $PWD/smp/config:/etc/opt/simplex \
  -v $PWD/smp/logs:/var/opt/simplex \
  simplexchat/smp-server:latest

The first start runs an init that generates the server's key pair and prints an address of the form smp://<fingerprint>@relay.example.com. That fingerprint is what clients pin, so keep the key files in the mounted config volume and back them up; regenerate them and every contact whose queues are on your server silently loses the link. The same pattern applies to simplexchat/xftp-server, with a storage path and a quota you set in its config file. The project's server docs cover the init flags, including setting a server password so only you can create queues on it, which you want unless you intend to run a public relay.

Adding it in the app is a settings toggle, not a migration

In the mobile or desktop client, go to Settings, then Network and servers, add the smp:// address and enable it for new connections. New contacts you connect to from then on get their queues to you placed on your relay. Existing contacts keep working on the old servers until the client rotates their queues, which it does over time. Nothing needs re-adding and no one else has to change anything. The XFTP address goes in the same screen, and it only affects files you send. I'd keep at least one of the preset servers enabled as well so that a reboot of your VPS does not take your inbox offline; the client will use any enabled server for redundancy.

Where it is still rough

The protocol is young, with a first release in 2021, and it shows in two places. Groups are implemented as every member sending to every other member's queues, so a 200-person group generates a lot of traffic and is slower to sync than a Matrix room, and admin tooling is thinner. The other is convenience: with no identifiers there is no "find my friends by phone number", and onboarding someone means sending them a link or QR code in person or over another channel. Those are the price of the design, not bugs, and the project is honest about them. For a federated room-based system with better group ergonomics, Synapse remains the answer; the communication category lays out that split.

What I'd do

Rent the cheapest VPS you can find with a static IP, run the SMP and XFTP containers with a server password set, put the address in your own clients and in the clients of the three or four people you talk to most, and leave the preset servers enabled as fallback. Back up the key directories once, because they never change. That is under an hour of work and about 4 to 5 dollars a month for a messenger where the only party that can watch your traffic patterns is you. If you do not have a specific reason to care about metadata, use SimpleX with the default relays and spend the evening elsewhere.

Compare SimpleX Chat

10 head-to-head comparisons.

Similar chat & communication apps