charts/charts-wip/matrix-synapse
2020-08-09 11:16:36 +02:00
..
charts Remove accidental unpacked postgres chart 2020-08-09 00:17:47 +02:00
templates Clean up WIP synapse chart 2020-08-09 11:16:36 +02:00
.helmignore Save work on WIP Matrix Synapse chart 2020-08-07 23:23:34 +02:00
Chart.lock Save work on WIP Matrix Synapse chart 2020-08-07 23:23:34 +02:00
Chart.yaml More synapse chart work 2020-08-09 00:15:10 +02:00
README.md Clean up WIP synapse chart 2020-08-09 11:16:36 +02:00
values.yaml Clean up WIP synapse chart 2020-08-09 11:16:36 +02:00

Matrix Synapse

Synapse is the current reference implementation of the Matrix protocol.

Prerequisites

  • Kubernetes 1.15+
  • Helm 3.0+
  • Ingress installed in the cluster

NB; Matrix requires the use of valid certificates.

Installing

To run a federating Matrix server, you need to have a publicly accessible subdomain that Kubernetes has an ingress on.
You will also require some federation guides, either in the form of a .well-known/matrix/server server or as an SRV record in DNS.

When using a well-known entry, you will need to have a valid cert for whatever subdomain you wish to serve Synapse on. When using an SRV record, you will additionally need a valid cert for the main domain that you're using for your MXIDs.

Installation Examples

Refer to the main Synapse docs for more information.

On main domain / with subdomain MXIDs

For the simplest possible Matrix install, you can run your Synapse install on the root of the domain you wish in your MXIDs. If you - for instance - own the domain chosenin.space and want to run Matrix on it, you would simply install the chart as;

helm install matrix-synapse --set config.serverName=chosenin.space --set wellknown.enabled=true

This would set up Synapse with client-server and federation both exposed on chosenin.space/_matrix, as well as a tiny lighttpd server that responds to federation lookups on chosenin.space/.well-known/matrix/server.

You can also use this to run a Synapse on a subdomain, with said subdomain as part of your MXIDs; (@user:matrix.chosenin.space in this case)

helm install matrix-synapse --set config.serverName=matrix.chosenin.space --set wellknown.enabled=true

On separate subdomain

If - on the other hand - you own the domain example.com, want your MXIDs in the form @user:example.com, but still want to run your Synapse on matrix.example.com. Then you have two options, using either DNS or well-known;

For DNS, you could install the chart as;

helm install matrix-synapse --set config.serverName=example.com --set config.publicBaseUrl=https://matrix.example.com --set ingress.includeServerName=false --set ingress.hosts={example.com} --set ingress.csHosts={matrix.example.com} 

This will add only federation endpoints to example.com, along with client endpoints on matrix.example.com. You will also need to have valid certs for both example.com as well as matrix.example.com for your Synapse to use. To get federation working with such a setup, you would need to add an SRV record to your DNS - for example;
_matrix._tcp.example.com 10 1 443 matrix.example.com

If you want to use a well-known file for federation instead, then your install might look more like;

helm install matrix-synapse --set config.serverName=example.com --set config.publicBaseUrl=https://matrix.example.com --set wellknown.enabled=true --set wellknown.host=matrix.example.com --set ingress.includeServerName=false --set ingress.hosts={matrix.example.com} --set ingress.csHosts={matrix.example.com} --set ingress.wkHosts={example.com}

With well-known federation, your client-to-server/public host is the one that needs to handle both client and federation traffic. On your main domain you'll instead only need something that can respond with a JSON file on the URL example.com/.well-known/matrix/server, which the included wellknown server will do.
When using well-known federation, your Synapse cert would only need to be valid for matrix.example.com.