When is ESS Community enough, and when does a self-hosted Matrix deployment need ESS Pro?
A team that wants its own Matrix homeserver has to decide early which Element edition to run. ESS Community fits non-commercial use, evaluations and small deployments of 1 to 100 users, while commercial or regulated production use points to ESS Pro. Element's own ESS Community page describes Community as intended for non-professional use, evaluations and small to mid-sized deployments, and Element states that commercial users should use ESS Pro to meet obligations such as the Cyber Resilience Act. Treat that statement as the vendor's position and check it against your own use before you deploy.
Community is still a reasonable choice in a few situations: a trial to learn how Synapse, Matrix Authentication Service and Element Web fit together, an internal lab that never carries business communications, or a small non-commercial group that accepts no performance guarantees and no vendor security update management. In those cases, confirm the user count, the licensing position of your organization and whether anyone outside the group will depend on the service. If the answer to any of these changes later, plan the move to Pro rather than assuming Community can stay in place, because the ESS Community page states that it can be upgraded to ESS Pro.
Before you commit, ask Element for a written quote covering the seat count, the production and test server limits, and whether the air-gapped or self-hosted option matches your network. Pro is priced per seat per month through sales, so the recurring cost grows with the user base, while the infrastructure and operating effort stay with your team. Confirm what the subscription includes for LTS releases, security advisories and SBOMs, since those are the controls a regulated buyer usually needs to evidence.
Which features sit in Community and which require ESS Pro?
This table lists the capabilities Element documents for ESS Community and ESS Pro, so you can see where a production requirement falls. Each cell reflects what Element's own pages state, and you should confirm current details on the vendor's pricing and product pages before you decide.
| Capability | ESS Community | ESS Pro |
|---|---|---|
| Synapse homeserver edition | Community Synapse, which Element describes as not for production use | Synapse Pro, which Element positions as a homeserver for professional use |
| Dynamic scaling and autoscaling | Not included, per Element's ESS Community page | Included with Synapse Pro, per Element's pricing page |
| Multi-tenancy | Not included, per Element's ESS Community page | Not listed as a Pro feature in Element's pricing summary, so confirm with Element |
| Advanced identity and role-based access | Not included, per Element's ESS Community page | LDAP or Active Directory and SCIM integration, plus OIDC SSO, per Element's pricing page |
| Security advisories and packaged security updates | Not included, and Community has no security update management | Advance security advisories and LTS releases with backported critical fixes, per Element's pricing page |
| Auditing and retention | Auditing not included, per Element's ESS Community page | In-room auditing and retention policies, per Element's pricing page |
| High availability and S3 media storage | Not listed as a Community feature | High availability with rolling updates and S3 media storage, per Element's pricing page |
| SLA, SBOMs and CRA support | No SLA, no SBOM and not Cyber Resilience Act compliant, per Element's ESS Community page | SLA and SBOMs for CRA compliance, per Element's pricing page; confirm the SLA terms in writing |
How licensing, support and update terms differ between the two editions
Element Server Suite Community and ESS Pro share the same Synapse codebase, but the terms around them differ sharply. The cards below separate what the AGPLv3 license permits from what Element commits to in writing, and show where an enterprise needs to check obligations before choosing an edition.
AGPLv3 license on Community
ESS Community is distributed under AGPLv3, which permits use, modification and redistribution with source obligations attached. The license itself is not the limit: Element's Community page restricts the distribution to non-commercial, non-professional use and evaluations of 1 to 100 users. Check whether your deployment is a commercial use under that positioning before you rely on Community in production.
No guarantees on Community
Element states that Community comes with no performance guarantees, no certifications, no software bill of materials and no vendor responsibility or security update management. Your team carries patching, incident response and performance tuning. Ask whether an internal owner accepts that responsibility in writing before a go-live date is set.
Regulatory fit under the CRA
Element says Community is not Cyber Resilience Act compliant and that commercial users should use ESS Pro to meet legislation such as the CRA. ESS Pro lists SBOMs for CRA compliance as a feature. Confirm with your legal and compliance team which obligations apply to your organization and product before deciding which edition satisfies them.
ESS Pro sales-led terms and SLA
ESS Pro is priced per seat per month through sales, and Element lists an SLA among its Pro features. The SLA terms, service credits and response commitments are set in the contract, not on the pricing page. Request the SLA document, its severity definitions and its exclusions during procurement, and confirm whether it covers self-hosted or air-gapped deployments.
LTS releases and advance advisories
ESS Pro ships LTS versions every 6 months with backported critical security fixes and advance security advisories. These commitments shape your upgrade calendar: an LTS line lets you apply fixes without taking every feature release. Ask Element for the support window of each LTS line and how advance advisories reach your team.
Synapse relicensing and AGPL exceptions
On December 13, 2023, Element moved future Synapse contributions from Apache 2.0 to AGPLv3, moved the repositories to element-hq, and began selling AGPL exceptions, with contributors signing a CLA. For an enterprise, this means the open-source obligations of AGPL apply to modified Synapse code, and a commercial exception is a separate contract. Have counsel map which of your modifications, hosted services or internal forks trigger source disclosure.
What do Element's production and Cyber Resilience Act warnings mean for your deployment?
The Community distribution is not positioned for production, and that single fact decides a lot of this comparison before any feature is weighed. Element's ESS Community page says Community comes with no performance guarantees, no certifications, no software bill of materials and no vendor responsibility or security update management, and that it is not Cyber Resilience Act compliant. Element's pricing page describes the Community Synapse homeserver as not for use in production environments. If your Matrix service will hold regulated or customer data, treat Community as a test or evaluation build and plan the production path around ESS Pro from the start, not as a later upgrade.
A compliance team needs evidence, and Community supplies very little of it. The missing software bill of materials is the first gap: an SBOM is the inventory of components a reviewer uses to check licenses and known vulnerabilities, and Element lists SBOMs as an ESS Pro feature. The second gap is packaged security updates and advance security advisories, which Element places in Pro. Ask Element in writing which SBOM format, release cadence and advisory channel apply to the specific ESS Pro tier you are quoting, and ask how backported critical fixes reach LTS releases. Those answers become the evidence set your auditors or customers will ask for.
DeployOpen plans, implements, hardens and documents self-hosted systems, and prepares controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it cannot tell you that a deployment is CRA compliant. Confirm your obligations under the Cyber Resilience Act with your legal counsel and, where relevant, the market surveillance or regulatory authority in your jurisdiction, including which products and roles in your chain are in scope and what conformity steps apply. Once that scope is settled, a written assessment of your evidence gaps against Element's ESS Pro documentation is a sensible first deliverable.
How do you move from ESS Community to ESS Pro without rebuilding the server?
The sequence takes a running Community deployment to a tested Pro production server, with the seat count, database, Synapse version and rollback position settled before any change reaches users. Element's ESS Community page states that Community can be upgraded to ESS Pro, so the move is a documented upgrade path that still needs written confirmation of the steps.
Confirm the upgrade path with Element
The platform owner asks Element, in writing, how an existing Community deployment is upgraded to ESS Pro. Ask whether user accounts, rooms, media, signing keys and configuration carry over in place, which components are replaced, and what downtime to expect. Element's ESS Community page confirms the upgrade is possible, but it does not describe the procedure, so the answer must come from the vendor. Done when you hold a written upgrade procedure for your exact Community version.
Confirm Pro seats and server limits
Element prices ESS Pro per seat per month through its sales team, and each setup is limited to one production server and one test server. Additional servers fall under the same price minimums. Count the active users you will bill, not accounts you hope to add later, and ask for a quote that lists seats, the production server, the test server and any extra servers. Community is positioned for 1 to 100 users and non-commercial use, so confirm that your organization is outside that scope before you commit. Done when the quote matches your user count and server plan.
Plan PostgreSQL and Synapse versions
Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Synapse documentation recommends PostgreSQL for production, and SQLite is also supported. Record the database engine and version your Community server runs now. If it is SQLite or an older PostgreSQL, schedule the database change before the Synapse change. Ask Element which Synapse release the Pro bundle ships with, and check it against these minimums. Done when you have a written version matrix covering the database, Python and Synapse.
Review rollback risk in upgrade notes
The Synapse upgrade notes warn that rolling back can be difficult because database schema changes occur between releases. Treat the database change as one-way in practice. Take a consistent PostgreSQL backup, copy the media store and the configuration files, and write a restore procedure with named owners. Reverse moves from Pro to Community carry the same risk, and the supplied facts do not describe a documented reverse path, so ask Element to confirm one before you rely on it. Done when a restore has been written down and the backup has been verified.
Rehearse the upgrade on test server
The team builds the Pro test server first, restores a copy of production data into it and runs the upgrade there. Check login through your identity provider, federation with a second homeserver, media uploads and downloads, admin functions and any LDAP, SCIM or OIDC integration you use. Restored copies contain personal data, so apply the same access controls as production. Log every error, the time each step took and the fix applied. Done when the test run completes without open defects and the findings are recorded in a sign-off document.
Cut over production after sign off
The team schedules a change window with the stakeholders who depend on the server and freezes configuration changes for that period. It then takes a fresh backup of the database, media and configuration, runs the same upgrade steps used in testing on the production server, and repeats the checks from the test run. Keep the pre-upgrade backup until the production server has run stably for a period the team sets in advance. Done when the post-upgrade checklist is complete, the backup retention decision is recorded and the server is handed back to operations.
What drives the cost of ESS Pro for different organizations?
A small internal team usually has a modest seat count, one production homeserver and a need for a test environment. ESS Pro is priced per seat per month through sales, so the seat count your team commits to is the main recurring driver. Element limits each setup to one production server and one test server, which fits a single-site team that does not need a separate staging cluster. If the team later adds a server, the additional server is subject to the same price minimums, so the cost can step up sooner than the seat count suggests.
- Per-seat monthly pricing: Ask whether the quote counts named users, active users or all accounts on the homeserver, and whether bots and service accounts are included.
- One production and one test server: Confirm that the quoted setup covers exactly these two servers and what it costs to add a third.
- Additional server minimums: Ask for the minimum charge per extra server and whether it applies to a development or disaster recovery node.
- Recurring versus one-time charges: Separate the recurring subscription from any one-time onboarding or setup fees, and confirm the billing period.
- Support and SLA terms: Ask which support level and service commitments are included in the seat price.
Before you request the quote, confirm the planned user count and whether a test server is needed from day one.
A multi-site enterprise tends to run several regions, business units or tenants, and each may want its own production path. The per-seat price scales with the users across all sites, while the one production and one test server limit means every extra production deployment is a separate cost decision. Element's pricing page also points to dynamic scaling in Synapse Pro, which matters for sites with uneven peak loads, but the quote should show how scaling is priced rather than assuming it is included in the seat rate.
- Seats across sites: Ask whether seats are pooled across all sites or priced per deployment, since this changes the total for a federated or split user base.
- Additional production servers: Request a line item for each extra production server, including the minimum charge that applies.
- Staging and disaster recovery: Confirm whether a second test server, a standby or a disaster recovery copy is priced as an additional server.
- High availability and rolling updates: Ask which high availability features are in scope, and whether they require extra servers or only configuration.
- Identity and auditing scope: Ask whether LDAP or Active Directory, SCIM, OIDC SSO and in-room auditing are priced into the base or as add-ons.
Ask for the seat count per site, the number of production and test servers, and a written statement of what each extra server adds to the total.
An air-gapped public sector deployment changes the cost model in two ways. Element offers ESS Pro self-hosted or air-gapped, and the air-gapped setup includes a custom mobile push gateway, which is not a standard component of a connected deployment. Because push traffic cannot reach a public service in the usual way, the gateway design, its hosting and its update process become part of the scope. The per-seat price, the server limits and the minimums still apply, but the implementation and operating effort can be a larger share of the total.
- Custom mobile push gateway: Ask what the gateway is, who builds and hosts it, and what it costs to update it inside an isolated network.
- Air-gapped delivery and updates: Confirm how packages, LTS releases and security fixes reach an isolated environment, and whether that process is priced separately.
- Seat and server pricing: Confirm that the same per-seat and server minimums apply to air-gapped setups, and whether any environment-specific minimums exist.
- Compliance documentation: Ask for the SBOMs and advance security advisories included in the quote, since these support Cyber Resilience Act and procurement reviews.
- Implementation and support: Ask who performs installation inside the isolated network and what support is available when external access is limited.
Ask the vendor to state every component of the air-gapped scope in writing, including the push gateway, update path and documentation, before comparing totals with a connected deployment.
Questions buyers ask before choosing ESS Pro or staying on Community
Can our company use ESS Community for internal Matrix chat?
Element positions ESS Community for non-commercial Matrix deployments, intended for non-professional use, evaluations and small to mid-sized deployments of 1 to 100 users. If your organization is a commercial business using Matrix for staff communication, Element's own ESS Community page says commercial users should use ESS Pro. Read the license terms and Element's stated positioning with your legal and procurement teams before you deploy, because the answer depends on how your company uses the service, not on the software alone. Confirm the positioning in writing with Element if the deployment serves paying customers or regulated workloads.
What does ESS Pro cost, and how is it quoted?
Element does not publish a single fixed figure in the supplied material. Its pricing page says it prices ESS Pro per seat per month through sales, offers it self-hosted or air-gapped with a custom mobile push gateway, and limits each setup to one production server and one test server, with additional servers subject to the same price minimums. Cost therefore follows seat count, the number of servers, and whether you need air-gapped delivery. Ask Element for a written quote that states the seat basis, minimums, the number of production and test servers, support level, and whether the mobile push gateway is included.
How long does a move from ESS Community to ESS Pro take?
No duration is supplied for this move, so treat any timeline as something to confirm in a written scope. The work depends on whether you are upgrading an existing ESS Community install in place or rebuilding the stack, how much data sits in the Synapse database and media store, how many users and rooms you have, and whether you are adding LDAP or SCIM, S3 media storage, high availability or retention policies at the same time. Each added integration adds testing. Ask the vendor and any implementation partner to list the upgrade path, rollback steps and the test cases they will run before cutover.
Can our team run ESS Community without outside help?
A team with Kubernetes, Helm, PostgreSQL and reverse proxy experience can install and run ESS Community, since Element deploys it on Kubernetes with Helm charts. Community, however, comes with no performance guarantees, no certifications, no software bill of materials, and no vendor responsibility or security update management. Your team would own patching, incident response, backup testing and upgrades. Assess whether you have staff for that ongoing work, and whether the users you serve can tolerate outages from your own mistakes. Outside help is most useful for hardening, backup and restore testing, and upgrade planning.
What does LDAP and SCIM integration need from our directory?
LDAP or Active Directory and SCIM integration are listed as ESS Pro features, so they are not part of the Community distribution. Before you scope the work, confirm which directory you run, how users and groups are structured, which attributes map to Matrix identities, whether accounts are disabled through SCIM deprovisioning, and who owns the directory service accounts. Synapse separately supports OpenID Connect, SAML2 and CAS single sign-on, so decide which identity path you need. Check the chosen mapping against a test directory before production use.
Can DeployOpen implement, harden and support either ESS edition?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support or upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen is not an official partner or reseller of Element unless that is stated in a supplied fact, so confirm your licensing for ESS Pro directly with Element.
Does ESS Pro certify our compliance with the Cyber Resilience Act?
No. ESS Community is not Cyber Resilience Act compliant, and Element states that commercial users should use ESS Pro to comply with legislation such as the CRA. Element's pricing page lists SBOMs for CRA compliance and advance security advisories among ESS Pro features, and says Element is certified to ISO/IEC 27001:2022 and holds Cyber Essentials Plus. Those are vendor statements about Element, not proof that your deployment is compliant. Ask Element for the current compliance documentation and have your own assessor or auditor decide what your obligations require.
Can your team run ESS Pro itself, or should it bring in an implementation partner?
Decide first whether your team can own ESS Pro day to day, because the work is less about installing the software and more about keeping a Kubernetes-hosted Matrix deployment running through routine change. ESS is deployed on Kubernetes with the provided Helm charts, so the team needs people who can manage Helm releases, cluster upgrades, persistent storage and network routing for Synapse, Matrix Authentication Service, Element Web and Element Call. Ask Element which components ESS Pro packages, and confirm which values you must set yourself for identity, media storage and high availability.
The database and identity work is where small teams most often stall. Synapse documentation recommends PostgreSQL for production and requires PostgreSQL 14 or newer from Synapse 1.143.0 onward, and the upgrade notes warn that rolling back can be difficult because of schema changes. Your team must own backups, restore tests and a staged upgrade path, and must test each LTS move in a non-production server before it reaches users. Identity is similar: LDAP or Active Directory, SCIM and OIDC SSO each need named owners, and the ESS Pro scope you buy should be checked against the directory you actually run.
A fixed-scope DeployOpen engagement fits when the team can run the platform but needs the design, hardening, integration and first upgrade rehearsals done in writing, with deliverables and dates agreed before work starts. A retainer for ongoing support and upgrades fits when you want someone to test each LTS release and produce the change records and evidence your compliance reviewers will ask for. In both cases, keep ownership of data, encryption keys, identity policy, retention decisions and the on-call rota, and ask for a written split of responsibilities that lists which party performs each recurring task.
How DeployOpen scopes, delivers and supports ESS Community and ESS Pro
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For Matrix, that means deciding with you whether ESS Community fits your user count and compliance position, or whether the ESS Pro path makes sense, before any installation starts.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the user count, identity sources, and whether ESS Community or ESS Pro is the target.
- Scope records any Cyber Resilience Act, audit or retention obligations that the chosen distribution must support.
How we build
- Deployment is planned inside your cloud accounts, data centers or air-gapped network, with Kubernetes and Helm settings reviewed first.
- Identity integration, such as OIDC, SAML or LDAP where the chosen edition supports it, is configured and tested against your directory.
- Federation settings, server_name and the federation listener are reviewed and firewalled to match your communication policy.
How we hand over
- Handover documents the installed components, versions, upgrade path and the licensing limits that apply to your setup.
- Backup and restore procedures are documented and exercised so your team can recover the homeserver and media store.
- Written runbooks cover the migration path between ESS Community and ESS Pro if your usage changes later.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Upgrade planning tracks Synapse release and database requirement changes before each rollout.
- Ask any provider to confirm in writing which vendor support, SLA and security advisories are included in your chosen edition.
