Please reach out our Element Sales Team if you want to run a Proof of Concept for Element Server Suite.
Note This guide is for running Proof of Concepts. We don't aim to show every feature here, we want to get you up and running most quickly. This guide is focusing on connected standalone installations currently.
Create an account on element.io
Communication via matrix space
3.1 Preparation of the VM
3.2 DNS names & certificates for the endpoints
3.3 Matrix IDs & Well Known delegation
3.4 Authentication & Postrgres DB
Please create an account on element.io. We will enable this account as part of the PoC process and grant you access to the Enterprise Server Suite software packages.
The account team will create a matrix room to improve communiclation and invite you. We will need your Matrix ID (MXID) for this. If you don't already have a MXID, you can create one here by signing up. This will create an account on matrix.org, you can authenticate via serverial identity providers. Send the MXID to the account team, so they can add you to the room. You could use the Element Web Client that you used to create the account or install one of the Element Mobile apps from the App or Playstore.
Element Server Suite can be installed in a Kubernetes Cluster or as a standalone installation on top of an Operating System (RHEL 8 or Ubuntu 20.04). Most Proof-of-Concept installations will select the Standalone Installation on top of a VM which we recommend for speed and ease of operation.
Click here for an overview of the Element Server Suite. Here is the link detailing the standalone installation.
Please set up a VM with 8 vCPUs and 32GB RAM and 100 GB Storage. If this sounds like a lot of resources to you, the requirements do in fact vary and could be scaled down later if required. Install Ubuntu 20.04 LTS or RHEL8. Update the system to the latest available patches and create a user to be used for maintaining the Element Server Suite. See our documentation for this step here.
You need to select a base domain for the Server. This can differ from the base domain of the matrix IDs but is often the same. Read more about this in the section on Matrix IDs and Well Known delegation below.
You have chosen eng.acme.com. The following DNS entries must be prepared and point to the external IP of the VM.
This results in the following hostnames for you :
Optional ( for webhooks & extensions ) :
Optional for Video Chat with Jitsi :
We require certificates for these hostnames to enable SSL/TLS encryption. The quick and easy way is to use the embedded letsencrypt. This is only available if you are in a connected environment. You provide and user your own certificates.
Matrix IDs have the following format :
In our example case the matrix server is matrix.eng.acme.com. If a user Tom Maier has a username tmaier in your LDAP, this would lead to an MXID @tmaier:matrix.eng.acme.com. This is often not desired as we like to keep the MXIDs short. It is more elegant to drop the "matrix" host name from the MXIDs. Tom's MXID would look like this @tmaier:eng.acme.com .
In order to be able to offer matrix IDs with the base domain, we recommend setting up a reverse proxy on eng.acme.com, which forwards https://eng.acme.com/.wellknown/matrix/ to the matrix/synapse server on https://matrix.eng.acme.com/.wellknown/matrix . Or you shorten the hostname part of your MXIDs even more to acme.com, this would require you to put the reverse provy onto acme.com.
More about wellknown and MXIDs can be found in our Upstream Documentation here and here.
Further configurations can be made using the wellknown mechanism. An example is documented here.
The quickest setup is using local authentication and users only. This is what we recommend for a first stip in a Proof-of-Concept situation. User accounts are created in the local Postgresql DB through our Admin UI or through API scripts for automation in this case. We support many mechanisms for AUthentication like LDAP, SAML2 and OIDC. We recommend to configure these as a 2nd step only if required.
You have the option to use an internal or external Postgres DB. We do recommend to use the internal Postgres DB for Proof-of-Concept installations. The internal Postgres DB is only available when you are opting for the Standalone Installation on top of an Operating System. You will need an external Postgres DB when installing into an existing Kubernetes cluster.
Please prepare the above items before starting the installation. Make sure you have :
Don't hesitate to reach out to your Element Sales Team for support. We are here to guide you.