-
Niranjan Kurhade authoredNiranjan Kurhade authored
Synapse 
Synapse is an open-source Matrix homeserver written and maintained by the Matrix.org Foundation. We began rapid development in 2014, reaching v1.0.0 in 2019. Development on Synapse and the Matrix protocol itself continues in earnest today.
Briefly, Matrix is an open standard for communications on the internet, supporting federation, encryption and VoIP. Matrix.org has more to say about the goals of the Matrix project, and the formal specification describes the technical details.
Contents
Installing and configuration
The Synapse documentation describes how to install Synapse. We recommend using Docker images or Debian packages from Matrix.org.
Synapse has a variety of config options which can be used to customise its behaviour after installation. There are additional details on how to configure Synapse for federation here.
Using a reverse proxy with Synapse
It is recommended to put a reverse proxy such as nginx, Apache, Caddy, HAProxy or relayd in front of Synapse. One advantage of doing so is that it means that you can expose the default https port (443) to Matrix clients without needing to run Synapse with root privileges. For information on configuring one, see the reverse proxy docs.
Upgrading an existing Synapse
The instructions for upgrading Synapse are in the upgrade notes. Please check these instructions as upgrading may require extra steps for some versions of Synapse.
Platform dependencies
Synapse uses a number of platform dependencies such as Python and PostgreSQL, and aims to follow supported upstream versions. See the deprecation policy for more details.
Security note
Matrix serves raw, user-supplied data in some APIs -- specifically the content repository endpoints.
Whilst we make a reasonable effort to mitigate against XSS attacks (for instance, by using CSP), a Matrix homeserver should not be hosted on a domain hosting other web applications. This especially applies to sharing the domain with Matrix web clients and other sensitive applications like webmail. See https://developer.github.com/changes/2014-04-25-user-content-security for more information.
Ideally, the homeserver should not simply be on a different subdomain, but on a completely different registered domain (also known as top-level site or eTLD+1). This is because some attacks are still possible as long as the two applications share the same registered domain.
To illustrate this with an example, if your Element Web or other sensitive web
application is hosted on A.example1.com, you should ideally host Synapse on
example2.com. Some amount of protection is offered by hosting on
B.example1.com instead, so this is also acceptable in some scenarios.
However, you should not host your Synapse on A.example1.com.
Note that all of the above refers exclusively to the domain used in Synapse's
public_baseurl setting. In particular, it has no bearing on the domain
mentioned in MXIDs hosted on that server.
Following this advice ensures that even if an XSS is found in Synapse, the impact to other applications will be minimal.
Testing a new installation
The easiest way to try out your new Synapse installation is by connecting to it from a web client.
Unless you are running a test instance of Synapse on your local machine, in general, you will need to enable TLS support before you can successfully connect from a client: see TLS certificates.
An easy way to get started is to login or register via Element at
https://app.element.io/#/login or https://app.element.io/#/register respectively.
You will need to change the server you are logging into from matrix.org
and instead specify a Homeserver URL of https://<server_name>:8448
(or just https://<server_name> if you are using a reverse proxy).
If you prefer to use another client, refer to our
client breakdown.