Requirements and Recommendations
Hardware
In general, regardless of if you pick the standalone server or Kubernetes deployment, you will need a base level of hardware to support the application.
For scenarios that utilise open federation, Element recommends a minimum of 8 vCPUs/CPUs and 32GB ram for the host(s) running synapse pods.
For scenarios that utilise closed federation, Element recommends a minimum of 6 vCPUs/CPUs and 16GB ram for the host(s) running synapse pods.
Software
To obtain our software, please visit our downloads page at: https://ems.element.io/on-premise/download
Kubernetes Application (Multiple Nodes)
For an installation into a kubernetes environment, make sure you have a Kubernetes platform deployed that you have access to and head over to Kubernetes Installations. You will also need a linux computer to run the installer from. That computer should be running RHEL 8 or RHEL 9 or Ubuntu.
Standalone (Single Node)
For a standalone installation, please note that we support these on the following platforms:
- Ubuntu Server 20.04
- Enterprise Linux 8 or 9 (RHEL, CentOS Stream, etc.)
Once you have a server with one of these installed, please head over to Single Node Installations
Airgapped Environments
If you are going to be installing into an airgapped environment (one without internet connectivity), you will need to also download the airgapped installer, which is ~6GB of data that will need to be transferred to your airgapped environment. More information on this can be found in our airgapped installation documentation here: https://ems-docs.element.io/books/element-on-premise-documentation/page/using-the-installer-in-an-air-gapped-environment
Environment
For each of the components you choose to deploy (excluding postgresql, groupsync and prometheus), you must provide a hostname on your network that meets this criteria:
- Fully resolvable to an IP address that is accessible from your clients.
- Signed PEM encoded certificates for the hostname in a crt/key pair. Certificates should be signed by an internet recognised authority, an internal to your company authority, or LetsEncrypt.
It is possible to deploy Element Enterprise On-Premise with self-signed certificates and without proper DNS in place, but this is not ideal as the mobile clients and federation do not work with self-signed certificates. Information on how to use self-signed certificates and hostname mappings instead of DNS can be found in How to Setup Local Host Resolution Without DNS
In addition to hostnames for each component, you will also need a hostname and PEM encoded certificate key/cert pair for your base domain. If we were deploying a domain called example.com
and wanted to deploy all of the software, we would have the following hostnames in our environment that needed to meet the above criteria:
-
Base Domain.
example.com -
Synapse.
matrix.example.com -
Element Web.
element.example.com -
Integration Manager.
integrator.example.com -
Admin Dashboard.
admin.example.com -
AdminBot.
adminbot.example.com -
AuditBot.
auditbot.example.com -
Hookshot.
hookshot.example.com -
Hydrogen.
hydrogen.example.com -
Jitsi.
jitsi.example.com -
Coturn.
coturn.example.com -
Element Call.
call.example.com -
SFU.
sfu.example.com -
Grafana.
grafana.example.com -
Telegram Bridge.
telegrambridge.example.com -
Teams Bridge.
teamsbridge.example.com
Wildcard certificates do work with our application and it would be possible to have a certificate that validated *.example.com and example.com for the above scenario. It is key to do both the base domain and the wildcard in the same certificate in order for this to work.
Further, if you want to do voice or video across network boundaries (ie: between people not on the same local network), you will need a TURN server. If you already have one, you do not have to set up coturn. If you do not already have a TURN server, you will want to set up coturn (our installer can do this for you) and if your server is behind NAT, you will need to have an external IP in order for coturn to work.