Requirements and Recommendations

Software

To obtain our software, you will need an EMS Account and associated Element Server Suite subscription.

Then simply access the Downloads page, and download the version you wish to install. It is strongly recommended to download the latest LTS version, you can ensure you are looking at LTS only releases by ensuring Show LTS Only is enabled:

Operating System

The installer binary requires a Linux OS to run, supported platforms inlude:

• Ubuntu.

  • Ubuntu Server 20.04

• Enterprise Linux. RHEL, CentOS Stream, etc.

  • Enterprise Linux 8
  • Enterprise Linux 9

For installation in Standalone mode, i.e. onto the host itself, only the above OS's are supported, otherwise for an installation into a Kubernetes environment, make sure you have a Kubernetes platform deployed that you have access to from the host running the installer.

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.

• Open Federation.
  Element recommends a minimum of 8 vCPUs/CPUs and 32GB ram for the host(s) running synapse pods.

• Closed Federation.
  Element recommends a minimum of 6 vCPUs/CPUs and 16GB ram for the host(s) running synapse pods.

Software

The values provided below are indicative and might vary a lot depending on your setup, the volume of federation traffic, active usage, bridged use-cases, integrations enabled, etc.

CPU & Memory

Synapse Homeserver

ToThe obtaininstaller ourcomes software,with please visit our downloads page at: https://ems.element.io/on-premise/download

Kubernetes Application (Multiple Nodes)

For andefault installation intoprofiles awhich kubernetesconfigure environment,workers makedepending sureon youyour havesetup. aFor Kuberneteseach platformprofile deployed:

that

you
• CPU haveis accessthe tomaximum andcpu headcores overthe toHomeserver Kubernetescan Installations.request
You
• Memory is the average memory the Homeserver will alsorequire
need

alinuxcomputerto

	1–500 runusers	501–2500 users	2501–10000 users
unfed	2 CPU, 2000 MiB RAM	6 CPU, 5650 MiB RAM	10 CPU, 8150 MiB RAM
small fed	2 CPU, 2000 MiB RAM	6 CPU, 5650 MiB RAM	10 CPU, 8150 MiB RAM
open fed	5 CPU, 4500 MiB RAM	9 CPU, 8150 MiB RAM	15 CPU, 11650 MiB RAM

PostgresSQL

Synapse Postgres Server

Synapse postgres server will require the installerfollowing from.resources That:

computer

	1–500 users	501–2500 users	2501–10000 users
unfed	1 CPU, 4 GiB RAM	2 CPU, 12 GiB RAM	4 CPU, 16 GiB RAM
small fed	2 CPU, 6 GiB RAM	4 CPU, 18 GiB RAM	8 CPU, 28 GiB RAM
open fed	3 CPU, 8 GiB RAM	5 CPU, 24 GiB RAM	10 CPU, 32 GiB RAM

Operator & Updater

The Updater memory usage remains at 256Mi. At least 1 CPU should be runningprovisioned RHELfor 8the oroperator RHELand 9the or Ubuntu.updater.

Standalone

The (SingleOperator Node)

memory usage scales linearly with the number of integrations you deploy with ESS. It's memory usage will remain low, but might spike up to 256Mi x Nb Integrations during deployment and configuration changes.

Volumes

Synapse Medias

ForThe disk usage to expect after a standaloneyear installation,can pleasebe notecalculated that we support these onusing the following platforms:formula : average media size x average number of media uploaded / day x active users x 365.

Media retention can be configured with the configuration option in Synapse/Config/Data Retention of the installer.

Postgres DB size

The disk usage to expect after a year can be calculated using the following formula :

• UbuntuIf ServerFederation 20.04is enabled, active users x 0.9GB.
• EnterpriseIf LinuxFederation 8is disabled or 9limited, (RHEL,active CentOSusers Stream,x etc.)0.6GB.

Once you have a server with one of these installed, please head over to Single Node Installations

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.

Airgapped Environments

An air-gapped environment is any environment in which the running hosts will not have access to the greater internet. As such these hosts will be unable to get access to the required software from Element and will also be unable to share telemetry data back with Element.

Your airgapped machine will still require access to airgapped linux repositories depending on your OS. If using Red Hat Enterprise Linux, you will also need access to the EPEL Repository in your airgapped environment.

If you are going to be installing into an airgapped environment, you will need a subscription including airgapped access and to then download the airgapped dependencies element-enterprise-installer-airgapped-<version>-gui.tar.gz file, which is a ~6GB archive that will need to be transferred to your airgapped environment.

Extract the archive, using tar -xzvf element-enterprise-installer-airgapped-<version>-gui.tar.gz so that you have an airgapped directory. Once complete, your host will be successfully setup for airgapped and ready for when you need to point the installer to that directory during installation.

For Kubernetes deployments, please note that once the image upload has been done, you will need to copy the airgapped/images/images_digests.yml file to the same path on the machine which will be used to render or deploy element services. Doing this, the new image digests will be used correctly in the kubernetes manifests used for deployment.