When ESS Community or a manual Synapse install fits
Choose ESS Community when you want a working Matrix server quickly, your use is non-commercial, and you are comfortable running a Kubernetes cluster. Element's ESS Community deploys a Matrix stack with Helm charts on a Kubernetes distribution of your choice, including a single-node K3s setup, and is aimed at small to mid-scale non-commercial use. Choose a manual install of Synapse, MAS and Element Web when you want direct control over each component's configuration, upgrade timing and database layout, and when your team can operate those pieces without a bundled chart. Before you commit, confirm the license position with your legal team: ESS Community is licensed AGPL-3.0 and positioned for non-commercial use, which may rule it out for an organization that needs commercial rights or support.
Manual installs fit teams that already run PostgreSQL, reverse proxies and Kubernetes or VM tooling, and that want to pin Synapse to a release they have tested. Synapse's upgrade notes warn that rolling back can be difficult because of database schema changes, so plan database backups and a staging environment before each upgrade. Check the minimum PostgreSQL and Python versions for the Synapse release you choose, since the upgrade notes tie them to specific releases. A manual install also means you own the single sign-on wiring through oidc_providers or saml2_config, the federation settings and the scaling decisions.
ESS Pro becomes the realistic option when you need high availability inside the cluster, automatic scaling, LDAP or SCIM user management, malware scanning of media, auditing or a Secure Border Gateway for federation controls, all of which the ess-helm README lists for ESS Pro rather than Community. Ask Element which ESS Pro features and support terms apply to your environment, and whether ESS Pro is offered for air-gapped deployments. Whichever path you take, DeployOpen can plan, install, harden, back up and document either stack inside your own infrastructure under a written, fixed scope.
How ESS Community and a manual install differ by situation
A single-node pilot is the situation where ESS Community is easiest to justify. The ESS Community Helm charts deploy a Matrix stack on a Kubernetes distribution of your choice, and the ESS README describes a single-node K3s setup. A manual install instead means you place Synapse, the Matrix Authentication Service and Element Web on a VM or container host yourself, then write the reverse proxy, TLS and database configuration by hand. In both cases you own the host. With ESS, you also own the K3s node, its kubelet and the Helm releases. With a manual install, you own the operating system, the Python runtime for Synapse and the service units.
- What you run: ESS on a single K3s node, or Synapse, MAS and Element Web as separate services on one host.
- Who maintains the layer below: Your team maintains the K3s or VM host in both cases. Element does not maintain your cluster.
- Upgrade with ESS: You move to a new chart release, such as 26.10.2 published on October 16, 2026, and review its values changes.
- Upgrade with a manual install: You upgrade Synapse, check the upgrade notes and handle database schema changes yourself.
- Rollback risk: Synapse's upgrade notes warn that rolling back can be difficult because of database schema changes between releases.
Confirm before choosing a path whether your pilot will be torn down or kept, because a pilot that becomes production inherits the upgrade burden of whichever path you chose.
ESS Community is aimed at small to mid-scale non-commercial use, according to the ESS README, and it is licensed AGPL-3.0. A small team that wants a working Matrix service for a community or internal group gets a bundled set of components from the chart. A manual install gives the same team full control over each component's configuration but leaves the assembly work with them. Who is paid for that work matters here: if the team is volunteers or staff with other duties, the time to assemble and maintain the stack is often the real cost, while the software itself costs nothing under AGPL-3.0.
- What you run: The ESS Community chart on a single or small Kubernetes cluster, or a hand-built Synapse, MAS and Element Web deployment.
- Who maintains the layer below: The team maintains the cluster or host, backups and TLS certificates.
- Upgrade with ESS: Chart upgrades bundle the component versions Element tested together, which reduces decisions but ties you to the chart's pace.
- Upgrade with a manual install: Each component is upgraded separately, and Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life.
- Non-commercial limit: Check the ESS README for its non-commercial positioning before using Community in a business setting.
Confirm the intended use with Element and read the current Community terms before you deploy, since the positioning here is what the README states.
An organization that needs production controls should compare more than the install path. The ESS README describes ESS Pro as adding Synapse Pro with in-cluster high availability and automatic scaling, a Secure Border Gateway for federation controls, LDAP and SCIM user management, malware scanning of media and auditing. Those items are not part of the Community description, so a production plan built on Community must supply them another way or confirm the gap with Element. A manual install can use Synapse's own controls, such as the federation_domain_whitelist setting and OpenID Connect, SAML2 or CAS single sign-on, but each one is configured and tested by your team.
- What you run: Either ESS Pro under a commercial agreement, or a self-built stack with explicit controls for each gap.
- Who maintains the layer below: Your platform team maintains the Kubernetes cluster, including etcd backups and Secrets encryption at rest, since Kubernetes stores Secrets unencrypted by default.
- Federation: Synapse recommends firewalling the federation listener in addition to the whitelist.
- Identity: Synapse's SSO options and Kubernetes authentication are configured separately.
- Upgrades: Plan for Kubernetes minor version upgrades one step at a time, as the version skew policy requires.
Ask Element in writing which ESS Pro features apply to your environment, and have your security team review the Secrets and etcd plan before any production launch.
What ESS Community bundles and what you still assemble
ESS Community deploys a Matrix stack through Helm charts onto the Kubernetes distribution you choose, and the README includes a single-node K3s setup as one option. The chart is the unit of deployment, so the first task is to read the ess-helm README and the chart values for the release you plan to use, and confirm which Matrix components it installs, how each is configured, and which are optional. Do not assume a component is bundled because a manual install would need it. Record the chart version, such as release 26.10.2 published on October 16, 2026, and check that version against your change process before you pin it.
Several decisions stay with you regardless of the chart. You choose the Kubernetes distribution and its upgrade path, the ingress controller and how federation traffic reaches port 8448 or a delegated host on port 443, the certificate issuance and renewal method, the storage class for media and any persistent volumes, and whether PostgreSQL runs inside the cluster or as an external service that you back up and patch. Ask Element and your platform team to confirm which of these the chart can point at existing infrastructure. Each one is a recurring operating task, so assign an owner for it before go-live.
A manual install gives you a different split of work. You select and configure Synapse, Matrix Authentication Service and Element Web as separate deployments, which means you own their version pairing, their configuration files, their reverse proxy routing and their upgrade order. ESS Community removes much of that assembly, but it does not remove the Kubernetes skills, database operations or certificate management that Synapse itself requires. Before choosing, map each component to a named team and confirm that team can run it in your environment.
ESS Community and manual Synapse, factor by factor
This table compares Element Server Suite Community with a hand-built Synapse, Matrix Authentication Service and Element Web stack across licensing, bundled parts, Kubernetes, database, single sign-on, federation, upgrades and the path to ESS Pro. Read each row for the condition under which one option fits better, then confirm the points marked for vendor confirmation before you commit.
| Factor | ESS Community | Manual Synapse install |
|---|---|---|
| License and non-commercial limits | AGPL-3.0 licensed and aimed at small to mid-scale non-commercial use, so check whether your use case fits that positioning before you deploy it. | Synapse is AGPL-3.0 with commercial licenses available from Element, so a commercial deployment needs a license review either way. |
| Bundled components | Helm charts deploy the Matrix stack as one package, so the homeserver and related components arrive configured together. | You select and install Synapse, Matrix Authentication Service and Element Web yourself, which gives full control of versions and layout. |
| Kubernetes requirement | Requires a Kubernetes distribution of your choice, including single-node K3s, so you must operate a cluster even for a small deployment. | Runs on conventional servers or containers without Kubernetes, though you may still choose Kubernetes for consistency with other services. |
| Database | Database setup follows the chart configuration, so confirm that PostgreSQL is the database used for production in your chosen configuration. | Synapse recommends PostgreSQL for production and supports SQLite; versions 1.143.0 and later require PostgreSQL 14 or newer. |
| Single sign-on options | Confirm in the chart documentation which identity options are wired in and which need manual configuration. | Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS, so you choose and configure the protocol yourself. |
| Federation setup | Confirm how the chart exposes the federation listener, delegation and server_name before you publish the domain. | You set server_name, delegation and federation_domain_whitelist directly, and the docs advise firewalling the federation listener. |
| Upgrade ownership | The chart maintainers publish releases, but you still own the cluster upgrade and must follow Kubernetes version skew rules. | You own every Synapse, database and Python upgrade and must read upgrade notes, since rolling back can be difficult after schema changes. |
| Path to ESS Pro | ESS Pro adds Synapse Pro, in-cluster high availability, automatic scaling, LDAP and SCIM, and auditing, so Pro becomes the realistic choice when those needs appear. | Moving to ESS Pro later means reviewing your existing configuration and data layout against the chart, so confirm the migration path with Element before go-live. |
Architecture components each option asks you to run
Each card names one component of the Matrix stack and says who operates it. Element Server Suite Community deploys the Matrix pieces through Helm on a Kubernetes distribution you choose, but the cluster, its etcd, the database and the network path stay with your team. Read each card with the ESS Community chart documentation open to confirm which parts the chart manages.
Kubernetes control plane and etcd
The operator runs the control plane, and ESS Community does not install or maintain it for you. Kubeadm documents two topologies: stacked, with etcd on the control plane nodes, and external, with a separate etcd cluster. Both call for at least three control plane nodes behind a TCP load balancer on port 6443. Kubernetes recommends an odd number of etcd members, with five in production, and expects a tested etcd backup plan. Confirm which topology your platform team can operate before choosing a distribution.
Worker nodes and kubelet upgrades
Worker nodes run the Matrix pods, so your team sizes, patches and upgrades every node pool. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, before the other control plane components and the kubelets. Kubelets may trail the API server by up to three minor versions. Plan node upgrades as a separate change window from ESS chart upgrades. Ask the ESS Community documentation which node sizes it expects for your expected user count, and check that against your own load tests.
Synapse workers and Redis
Synapse scales by splitting work across worker processes, and Redis relays replication between the main process and those workers. Synapse documents this design, but confirm whether the ESS Community chart exposes worker configuration or runs a single Synapse process. Adding workers later means new routing at the reverse proxy and new Redis capacity to run. ESS Pro adds in-cluster high availability and automatic scaling, so check your worker needs before you commit to Community for a larger deployment.
PostgreSQL for Synapse
Synapse recommends PostgreSQL for production, and Synapse 1.143.0 and later require PostgreSQL 14 or newer. Confirm whether ESS Community deploys a database in the cluster or connects to one you operate before you size storage. Either way, backups, point-in-time recovery, minor version patching and major version upgrades remain your responsibility. Synapse warns that rolling back can be difficult because schemas change between releases, so take and test a database backup before every upgrade.
Matrix Authentication Service and sign-in
Matrix Authentication Service handles login and connects Matrix accounts to upstream identity providers. Synapse also supports OpenID Connect, SAML2 and CAS directly, so decide which layer owns sign-in before you install. Confirm whether ESS Community configures MAS and its upstream provider through chart values. LDAP and SCIM user management are features of ESS Pro, so if joiner and leaver automation matters, check whether Community covers it or whether you will build it yourself.
Element Web, ingress and federation paths
Element Web is the browser client, served over HTTPS through your ingress controller. Synapse federates on port 8448 by default, and delegation can serve user IDs such as @user:example.com from another host on port 443. DNS names, TLS certificates and the server_name setting must agree before anything else. Confirm which ingress controller and certificate manager the chart expects, and which firewall and load balancer rules you must open for client, well-known and federation traffic.
Upgrade and rollback work on a Matrix stack
Running ESS Community or a manual Synapse install means owning two upgrade tracks at once: the Kubernetes cluster underneath and the Matrix software on top. On the Kubernetes side, kube-apiserver must be upgraded one minor version at a time, and kube-controller-manager, kube-scheduler and kubelets follow after it. Kubelets may run up to three minor versions older than kube-apiserver, which gives a window to stage node upgrades, but it does not remove the need to plan each step. As a planning input, the Kubernetes project lists 1.37 with end of life on October 28, 2027, 1.36 on June 28, 2027 and 1.35 on February 28, 2027. Confirm which minor version your K3s or Kubernetes distribution tracks, because your chosen version sets how often you must upgrade and when you must move off a line.
The Synapse track is where most of the risk sits. Recent Synapse releases raise runtime floors: versions 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Because Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, a database upgrade may have to come before a Synapse upgrade. In an ESS Community deployment, check the chart's pinned Synapse and Matrix Authentication Service versions against the chart release notes before you change any value, and confirm with Element what supported path exists for your ESS release.
The Synapse upgrade notes warn that rolling back can be difficult because of database schema changes between releases. Treat a backup of the PostgreSQL database and the media store as a precondition for every Synapse upgrade, not an optional step, and rehearse a restore on a separate namespace before the production change. Record the exact chart version, image tags and homeserver.yaml values so you can reproduce the prior state. Whichever path you take, the work of testing upgrades, scheduling maintenance and keeping Kubernetes current is recurring, so ask any implementation partner to price it as an ongoing item, not a one-time install.
Upgrades, backups, monitoring and skills for each option
This table compares who carries the day-to-day operating work on each path: Kubernetes and etcd backups, Synapse database backups, chart and image upgrades, monitoring and the skills each team needs. Read the ESS Community column as the work the Helm chart packages for you, and the manual column as work your team owns end to end. The main takeaway is that ESS reduces deployment wiring, but the backup, restore, upgrade and on-call duties for your cluster and data stay with you.
| Area | ESS Community on K3s or Kubernetes | Manual Synapse, MAS and Element Web |
|---|---|---|
| Kubernetes and etcd backups | Your team still runs etcd snapshots with etcdctl snapshot save and restores with etcdutl on the cluster, because the chart does not manage the control plane | Not applicable at the cluster layer if Synapse runs on VMs or containers, but any Kubernetes footprint you add needs the same etcd backup and restore duties |
| Synapse database backup and restore | Confirm with your ESS deployment how PostgreSQL is provisioned and whether backups are included, then test a restore into a separate environment | Your team designs, schedules and tests PostgreSQL backups and restores for Synapse, including media storage, with no packaged default |
| Chart and image upgrades | Upgrade by moving the ess-helm chart and image versions together, reviewing release notes for each change, such as the 26.10.2 release | Upgrade Synapse, MAS and Element Web separately, following each project's upgrade notes and schema changes |
| Rollback planning | Confirm with Element whether a chart rollback also reverts database schema changes, since Synapse upgrade notes warn that rollback can be difficult | Plan rollback yourself, taking a database snapshot before each Synapse upgrade because schema changes can block a clean downgrade |
| Kubernetes version upkeep | Keep the cluster within supported Kubernetes minor versions, upgrading the API server first under the version skew policy | Only needed if you run Kubernetes yourself; otherwise upkeep applies to the host OS, Python and PostgreSQL versions Synapse requires |
| Monitoring | Monitor Kubernetes nodes, pods and etcd health alongside Synapse metrics, and confirm which ESS metrics and dashboards ship with the chart | Set up Synapse, PostgreSQL, reverse proxy and host monitoring from scratch, with alerting you define |
| On-call scope | Covers cluster incidents, etcd quorum loss, node failure and Matrix service faults, so the rota needs both layers | Covers service faults across Synapse, MAS, PostgreSQL and the proxy, with no cluster layer to triage |
| Skills required | Kubernetes operations, Helm, etcd, certificate and ingress management, plus Matrix federation and identity basics | Linux administration, PostgreSQL, Python service operations, reverse proxy and Matrix configuration knowledge |
How to decide when ESS Pro becomes the real choice
This sequence turns a vague sense that Community might not be enough into a written position on license fit, production needs and federation controls, ready to take to Element for a quote.
Confirm the license position for your use
Start by checking whether the deployment is non-commercial in the sense ESS Community describes. The ess-helm README positions Community for small to mid-scale non-commercial use, and ESS Community is AGPL-3.0. Legal or the compliance lead should write down who uses the service, whether it supports a paid business function, and whether any user population sits outside that positioning. The step is done when the organization has a signed-off statement of intended use that names the business owner. Confirm the current Community terms directly with Element, because license wording and positioning can change between releases.
List the production requirements in writing
Next, the platform owner lists every production requirement the service must meet, in plain terms. Typical items for a regulated team include in-cluster high availability, automatic scaling, directory-backed user lifecycle through LDAP or SCIM, malware scanning of media, and audit records of administrative and user activity. For each item, record who needs it, what failure or audit finding it prevents, and whether a manual workaround exists today. The output is a requirements register with one owner per line. Items that cannot be stated this way should be marked as open questions rather than assumed.
Map each requirement to the Community build
Compare the register against what ESS Community already provides in its Helm charts and what your team would build by hand around Synapse, MAS and Element Web. For each row, mark whether Community covers it, whether you would need to engineer it yourself, or whether it is only described for the Pro tier. Note the Kubernetes and etcd operating work that already applies in both paths. The step closes with a gap table showing which rows are covered, which require custom work, and which depend on ESS Pro features. Keep the table as evidence for the later quote request.
Check federation controls against policy
Decide whether the service must control federation with other homeservers. Synapse federates on port 8448 by default, and its federation_domain_whitelist setting can restrict federation to listed domains or disable it entirely. ESS Pro adds a Secure Border Gateway for federation controls. Security and network teams should decide whether an allowlist enforced in Synapse configuration, a firewall on the federation listener, or a gateway-level control meets the policy. The step is complete when the chosen approach is documented and tested in a non-production environment, and when the team knows whether the gateway is a requirement or a preference.
Assess support and upgrade obligations
Work out who will apply Synapse upgrades, Kubernetes minor version upgrades and database changes, and what happens when a release is not safe to roll back. Synapse upgrade notes warn that rollback can be difficult because of schema changes, and Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life. Kubernetes maintains only its three most recent minor releases. Record the team that owns each upgrade, the test environment used, and the support response you need. Where your team cannot staff this, it becomes a reason to ask Element about support tiers or to engage an implementation partner.
Write the Pro quote request
Turn the completed register, gap table and federation decision into a written request to Element. Ask for the current ESS Pro terms, what Synapse Pro, LTS releases, LDAP and SCIM, auditing, high availability and air-gapped support include, which components are licensed separately, how pricing scales with user count, and the support levels offered. Ask for any terms that depend on your deployment footprint. Do not rely on feature descriptions from older material, and confirm every item in writing. The step is done when Element has returned a quote that maps line by line to your register.
Decide and record the outcome
Review the quote and gap table with the business owner, security lead and platform team, then record a decision: stay on Community with named custom work, move to ESS Pro, or revisit the scope. Record the decision date, the owners of any residual gaps, and the trigger that would reopen the decision, such as a growth milestone, a new federation partner or an audit finding. A decision record that cites the license position, requirements register and quote gives auditors and future operators the reasoning they will ask for.
Identity, secrets and hardening on Kubernetes
Kubernetes does not store human users as API objects. It authenticates them with X.509 client certificates, bearer tokens including OpenID Connect and JWT, webhook token authentication or an authenticating proxy, so the identity decision for the cluster sits outside Synapse. Before you run ESS Community on K3s or Kubernetes, decide which of these paths your administrators use and who holds cluster-admin rights. Note that Synapse's own sign-in is a separate question: the configuration manual describes single sign-on through OpenID Connect (oidc_providers), SAML2 (saml2_config) and CAS, and the Matrix Authentication Service documents its upstream identity provider setup. Confirm with Element which of these paths the ESS Community chart wires up and which you would configure by hand in a manual install.
Kubernetes Secrets are stored unencrypted in etcd by default. The Secrets good practices page tells administrators to configure encryption at rest, restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. For a Synapse deployment, the Secrets that matter include the database password, the signing keys and any OIDC client secret. Ask who can read Secrets in the namespace, whether etcd snapshots are encrypted, and where your etcd backups are stored, because a snapshot taken with etcdctl snapshot save contains the same data. The same applies to any manual install that keeps configuration in files: check that the homeserver.yaml secrets and the Element Web deployment settings are not exposed through ConfigMaps or world-readable volumes.
Pod Security Standards define the baseline and restricted profiles that control what containers may request, such as privileged mode, host networking and root users. Apply them to the namespace that runs Synapse, workers and the reverse proxy, and test the chart's pods against the profile before production. For cluster-wide assurance, use the CIS Kubernetes Benchmark as the reference to map your control plane, worker nodes and policies against, and record each deviation with its reason. Mapping to the benchmark does not make a cluster compliant with it or with any other framework. An independent assessor or your own audit process decides that, and the work of preparing the evidence is what DeployOpen can help with.
Questions buyers ask before choosing ESS Community or a manual install
What drives the cost and effort of ESS Community compared with a manual Synapse install?
The main cost is the people time to build, operate and upgrade the stack, not the software, since ESS Community and Synapse are both AGPL-3.0 licensed. ESS Community bundles Helm charts for Synapse, MAS and Element Web on a Kubernetes distribution you choose, so much of the assembly work is already packaged. A manual install moves that assembly, configuration, database and reverse proxy work onto your team. Recurring costs include the Kubernetes cluster, PostgreSQL, storage, backups and the staff time for each upgrade. Ask any implementation partner for a written quote that separates one-time build work from recurring upgrade, monitoring and support work, and that names the Kubernetes distribution and database each option assumes.
How long does a Matrix homeserver setup take with ESS Community?
No fixed duration can be given here, because setup time depends on the team's Kubernetes skills, the existing cluster, identity integration and how much custom configuration is needed. ESS Community is aimed at small to mid-scale non-commercial use and offers a single-node K3s path, which can shorten the first deployment. Time usually goes to DNS, TLS certificates, federation settings, SSO and backup testing rather than the Helm install itself. Ask for a written timeline tied to a named scope, with milestones for a test environment, a restore test and a go-live review.
Can a team with Kubernetes experience run ESS Community alone?
A team with working Kubernetes experience can often deploy ESS Community alone, but running it in production also needs skills beyond the install. Your team must handle ingress, certificates, persistent volumes, PostgreSQL, Redis where used, secrets and upgrades. Kubernetes stores Secrets unencrypted in etcd by default, so you need encryption at rest and least-privilege RBAC, and an etcd backup plan is required for a control plane you run yourself. Check the ESS Community README and release notes before each upgrade, and confirm with Element that Community is appropriate for your use, since it is positioned for non-commercial use.
What does the team need to run a manual Synapse, MAS and Element Web deployment?
A manual install needs staff who can operate each component separately: the Synapse homeserver, Matrix Authentication Service, Element Web, PostgreSQL, a reverse proxy and federation routing. Synapse recommends PostgreSQL for production, and recent releases require PostgreSQL 14 or newer and Python 3.10 or newer, so your team must track dependency support windows. Upgrades need care because rolling back can be hard after database schema changes. Ask for a written runbook covering upgrade order, backup and restore tests, and monitoring for each component, and confirm which Synapse release line you plan to follow.
Can ESS Community move to ESS Pro later without rebuilding everything?
Moving from ESS Community to ESS Pro is a licensing and feature decision first, and a migration decision second. ESS Pro adds Synapse Pro with high availability and automatic scaling, a Secure Border Gateway for federation controls, LDAP and SCIM user management, malware scanning of media and auditing. Those features arrive with commercial terms from Element, so confirm the path, the contract and any change to the chart configuration with Element before you start. Ask for a written statement of what data, configuration and identity links carry over, and what downtime a switch would need.
When is an outside implementation partner worth scoping for an ESS or Synapse deployment?
An outside partner is worth scoping when the work exceeds what your team can staff and test, such as regulated identity integration, federation controls, backup and restore validation, hardening of the Kubernetes cluster or a documented handover. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so ask for a quote that lists the scope, deliverables, assumptions about your cluster, and what your team must provide.
What should a written quote for an ESS Community or manual Synapse project include?
A useful quote lists each component in scope, the environment it runs in and the responsibilities split between your team and the provider. Ask for the Kubernetes distribution and version, the PostgreSQL version, the identity provider and SSO method, the backup and restore test plan, the upgrade process and who performs it, and the handover documents. Separate one-time work such as design, deployment and testing from recurring work such as upgrades, monitoring and support. Also ask what is excluded, for example ESS Pro licensing, federation policy decisions or client device rollout, so cost differences are not caused by hidden scope.
Which Kubernetes upgrade rules affect an ESS Community cluster?
Kubernetes upgrades affect ESS Community because the cluster must stay within supported versions while the Matrix charts keep running. The version skew policy requires kube-apiserver to be upgraded one minor version at a time, before the controller manager, scheduler and kubelets, and kubelets may be up to three minor versions older than the API server. The project maintains the three most recent minor releases, so plan a recurring upgrade cadence rather than a one-off install. Confirm the Kubernetes version your chosen ESS release supports before scheduling any cluster change.
How DeployOpen scopes and delivers Matrix deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Matrix deployment, that means agreeing the homeserver, identity and client scope in writing first, then building and handing over the result with the evidence and runbooks your team needs to operate it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which Matrix components are in, such as the homeserver, identity service, web client and reverse proxy.
- Scope also covers federation intent, user count, database and storage choices, and which identity provider users will sign in with.
- Ask for the scope to name the licensing position for each component, since Community and paid editions differ.
How we build
- Deployment runs in your cloud accounts, data centers or air-gapped networks, on the Kubernetes distribution you choose.
- Work includes configuration of Helm or manual installs, identity integration, backup routines and hardening of the cluster and services.
- Security testing of the deployed applications and APIs can be included in the written scope if you request it.
- Confirm with us which customizations are in scope, since changes to upstream defaults affect later upgrades.
How we hand over
- Handover documents the architecture, configuration, backup and restore steps, and upgrade procedure for your own team.
- Compliance readiness material, such as controls and evidence for an assessment, is prepared for your auditors to review.
- DeployOpen does not issue audit reports, attestations or certifications, so independent assessors remain responsible for those.
- Ask for the handover package to be listed in the written scope so acceptance criteria are clear before work begins.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope build.
- A retainer can cover routine Synapse and Kubernetes upgrades, which need planning around database schema changes and version skew.
- Ask what response coverage and upgrade windows a retainer includes, and confirm those terms in the written agreement.
- DeployOpen does not publish a price list, so a quote follows from the written scope and the chosen support level.
