Managed Element hosting

Collaboration and identityOn-prem or sovereign site

Encrypted team messaging on the Matrix protocol: the Element apps on a Synapse homeserver you own, run in Switzerland, the EU or your own datacentre. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Element

Licence
AGPL-3.0-or-later
Runs on
Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades
Pinned, tested against your configuration, applied in your window
Upstream
element.io

Running Element in production: what it takes

  1. Settle domain and federation, then deploy

    Before the first room exists we fix the domain that ends every user ID, which cannot change later, and whether federation is closed, allow-listed or open. Then Synapse, the Matrix Authentication Service and Element Web go in on PostgreSQL, each pinned to a version we have run.

  2. Put sign-in behind your identity provider

    Accounts come from Keycloak or Entra ID through the Matrix Authentication Service, so nobody gets a new password. Leavers are locked or deactivated through its admin API as part of offboarding, not left to expire.

  3. Set up key recovery at rollout

    The server holds a backup of each person's message keys that it cannot open. A lost recovery key and a lost phone together mean lost history, so recovery is set up with everyone at rollout, not after the first phone goes missing.

  4. Back up both databases and the signing key

    A daily, encrypted copy of both databases, local media, the signing key and the configuration goes offsite. The monthly drill restores the set into a scratch environment and reads an encrypted room there with a test account.

  5. Upgrade once background updates finish

    Synapse migrates its database schema on start, and rolling back past a schema change is not always possible. The Pilae Agent tests each upgrade on a copy, lets background updates finish, waits for your approval and applies it in your window with the pre-upgrade backup ready.

What Element is, and who runs it

Element and Synapse: self-hosted Matrix messaging

Element is the set of apps people use: Element Web in the browser, Element Desktop, and Element X on iOS and Android. Behind them sits Synapse, the homeserver that stores rooms and relays messages, and the Matrix Authentication Service, which handles sign-in. All of it speaks Matrix, an open standard for chat, and when we say we operate Element we mean that whole stack. Private conversations are encrypted end to end by default, and Element Call adds encrypted voice and video with a LiveKit media server beside the homeserver. For meetings with guests who have no account, Jitsi Meet runs beside it, and Element Web can start a Jitsi call from a room.

Matrix is chosen where chat has to stay inside the organisation and still reach other organisations. Each runs its own server, and federation connects them. The French state’s Tchap, operated by DINUM for public servants, runs on Matrix, as does the Bundeswehr’s BwMessenger, built by its IT company BWI. NATO’s Allied Command Transformation uses NI2CE, a Matrix messenger that began as an experimental project led by its Innovation Hub. That is why Matrix comes up in the public sector and in international organisations.

Element in production: federation, keys and schema upgrades

Two things are decided before the first room exists: the domain at the end of every user ID, which cannot be changed later, and whether federation is closed, limited to an allow-list of partner domains, or open. Synapse and the Matrix Authentication Service run on PostgreSQL, in the Pilae Cloud region you choose or on your own hardware, and answer only on your private network. One hardened gate on port 443 carries what you choose to publish, such as mobile clients and allow-listed partners. Sign-in goes through Keycloak or Entra ID. When one Synapse process is no longer enough, it is split into workers coordinated through Redis.

Encryption moves the risk from the server to the people. The server cannot read an encrypted room and cannot give back a key someone has lost, so recovery is part of the rollout, not a helpdesk ticket later. Backups cover both databases, the local media, the signing key and the configuration, daily, encrypted, to an offsite location in your chosen country, and a monthly drill reads an encrypted room from the restored copy. Probes check the client and federation endpoints every 60 seconds and alert an engineer. Synapse migrates its schema on start and cannot always roll back, so every upgrade is rehearsed on a copy by the Pilae Agent and applied in your window once you approve it.

Element licence and editions

Sign-in through Keycloak or Entra ID works on the open-source components as they are, because the Matrix Authentication Service speaks OpenID Connect. AuditBot, for archiving encrypted rooms, is part of Element Server Suite Pro (see the licence note below). Whether you need Pro is settled in the proposal, before a server exists. Pricing for our operation is on request. Talk to us about the chat you want to bring in-house.

Synapse, the Matrix Authentication Service and the Element apps are published by Element under the AGPL-3.0, with a paid Element commercial licence as the alternative; Element Web and Element Desktop can also be taken under GPL-3.0. We run those open-source components. Element Server Suite Pro adds Synapse Pro for scaling and high availability, LDAP and SCIM provisioning, the Secure Border Gateway for federation control, content scanning, auditing and long-term support releases. Element describes its free Community distribution as meant for non-professional use and evaluations up to 100 users, and not intended for production in commercial environments. That is how Element positions its free distribution, not a condition of the AGPL, which sets no limit on users. If your requirements need ESS Pro, the licence is held in your name with Element and we say so in the proposal.

Element system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory
4 vCPU · 8 GBOur starting size for a few hundred people on a closed or allow-listed server. Joining large public rooms costs more than local users do, and Synapse can refuse rooms above a complexity limit.
Database
PostgreSQL 14+Synapse and the Matrix Authentication Service each get their own database. The Synapse one is created UTF8 with the C locale, which Synapse checks at start. SQLite is for testing only.
Media store
Persistent volumeUploads and avatars. Local uploads may be the only copy anywhere in the federation, so they are backed up with the database. Media cached from other servers is not.
Sign-in
OIDC via MASThe Matrix Authentication Service signs people in against Keycloak or Entra ID. It does not speak SAML or LDAP, so a directory that only offers those goes through Keycloak.
DNS and TLS
/.well-known/matrixUser IDs end in your own domain, such as @anna:acme.ch, so your main website serves two small files that point clients and other servers at the homeserver. That domain cannot be changed later.

Migrating from Microsoft Teams chat to Element

Teams chat history does not move. Synapse and Element have no importer for it, so it stays in Microsoft 365 under your retention policy, or is exported with Microsoft's own tools and kept as an archive. What moves is the structure and the people: each team becomes a space, each channel a room, and people sign in with the account they already use. Bots and connectors are rebuilt as Hookshot webhooks. Webinars and town halls, telephony and co-editing inside a chat are not part of Element, and we say up front which of them you will still need elsewhere. The effort goes into encryption: every person sets up recovery and verifies their devices in the first week, because a lost key cannot be recovered by anyone, us included.

  1. Decide where the Teams history lives

    Retention in Microsoft 365, or an export kept for the record. We agree which, and the cut-off date, before anything is built.

  2. Rebuild the structure

    Spaces and rooms are created from an inventory of your teams and channels, with encryption set per room and membership taken from your directory groups. Each bot and connector on the inventory is rebuilt as its own webhook.

  3. Sign in and set up recovery

    People sign in with the directory account they use today. At first sign-in each person saves a recovery key and verifies a second device, with a short guide and a named contact for that week.

  4. Switch team by team

    The desktop and mobile apps are installed ahead of the switch. Each team stops posting in Teams on an agreed day, and partner organisations are added to the federation allow-list as they come on.

What a Synapse restore needs

  • postgres/synapsepg_dump -Fc, 38 GB
    • events, event_jsonroom history, ciphertext in encrypted rooms
    • e2e_room_keyskey backup, encrypted on the device
    • e2e_one_time_keys_jsonexcluded from the dump
  • postgres/masaccounts, sessions, IdP links, 0.3 GB
  • media_storeuploads and avatars
    • local_content540 GB, may be the only copy
    • local_thumbnailsbacked up, no tool rebuilds them
    • remote_contentcache from other servers, skipped
  • confighomeserver.yaml, log config, MAS config
    • acme.ch.signing.keysigns events and federation requests
    • mas secretsencryption key, must not change
  • offsite copyencrypted, daily, in Switzerland
An example backup set for acme. A restore needs both databases, the local media, the signing key and the MAS secrets from the same night. The one-time keys table is left out on purpose: restoring it re-issues keys already used, and people see messages they cannot decrypt.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs
zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials
You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave
The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running Element

Pricing is on request: a fixed price for onboarding, then a monthly price for Element, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size
The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability
One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups
How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support
Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region
Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations
Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Element: common questions

Is Element open source?

Yes. Synapse, the Matrix Authentication Service and the Element apps are published under the AGPL-3.0, with a commercial licence from Element as the alternative. Element Server Suite Pro adds Synapse Pro, LDAP and SCIM provisioning, the Secure Border Gateway and auditing under a commercial licence, held in your name with Element if you need them.

Where are our messages stored?

On your own homeserver: PostgreSQL and a media volume on your hardware, or on dedicated machines in one of 12 Pilae regions, six of them in Switzerland and the EU. Encrypted rooms are stored as ciphertext the server cannot read. Mobile notifications for the public Element apps pass through a push gateway and Apple or Google, and carry room and event identifiers rather than the message.

Can we import our Teams chat history?

No. Synapse and Element have no importer for Teams chat. The history stays in Microsoft 365 under your retention policy, or goes into an archive exported with Microsoft tools, and conversations in Element start from the agreed cut-off date.

Can our compliance team search encrypted conversations?

Not from the server, which only holds ciphertext. This is the main difference from Teams, where Microsoft compliance tools can search chat. Element Desktop searches encrypted rooms through a local index on the device; the web app cannot. Where a rule requires an archive, the options are unencrypted rooms for that purpose or Element AuditBot under ESS Pro, and we settle which before rollout.

Do we have to federate with the public Matrix network?

No. An empty allow-list turns federation off, and a list of named domains limits it to partners. In a room shared with a partner, their server keeps its own copy of that room, so the list is a residency decision as well as a security one. We also restrict federation traffic at the gate, as upstream recommends, rather than relying on the setting alone.

Also in collaboration and identity

Back to apps

Bring us your Element. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.