Which Mattermost deployment model fits your team
The Kubernetes Operator pays off when your organization already runs clusters and needs high availability; otherwise the single Linux binary with PostgreSQL is a valid production path. The Operator is the path Mattermost recommends for most Kubernetes and cloud-native production deployments, pairing the application with S3-compatible storage and a managed database service. The gating matters before any architecture discussion: the Kubernetes deployment is available on the Entry, Enterprise and Enterprise Advanced plans but not on Professional, and high availability clustering is limited to Enterprise and Enterprise Advanced. If you are on Professional, the Operator is not an option, and HA is out of reach on either hosting model.
Kubernetes earns its operating cost mainly where a platform team already patches clusters, manages etcd backups, and enforces pod security and secrets handling. Those duties exist whether or not Mattermost runs on the cluster, so the marginal cost of adding one more workload is lower for a team that already does them. A small team without that capacity takes on the control plane, load balancers and storage classes as new work. We cannot give you a team-size threshold, because the answer depends on your operating capacity and your HA requirements. Ask Mattermost to confirm which plan you need for your user count, which storage types they have tested for filestores on Kubernetes volume mounts, and whether their support covers your cluster distribution.
Decide on the file store before you decide on the platform. An HA cluster needs shared file storage on Amazon S3, an S3-compatible service or NAS mounted on each node, because local file system storage will not work correctly and risks corrupting files. Mattermost also recommends an NFS volume when filestores use Kubernetes volume mounts and notes that not all persistent volume types have been tested. Confirm the storage design in writing with Mattermost and your cluster provider, and treat the choice of object storage or NFS as a risk to plan for, not a detail to settle later. Check the Mattermost Kubernetes deployment guide against your own storage and plan entitlements before you commit.
Operator on Kubernetes vs Linux install, factor by factor
This table compares the Mattermost Kubernetes Operator with S3-compatible storage and a managed database against a single Linux binary with PostgreSQL. Read each row as a decision point: the left column names the factor, and the cells show what each path asks of your team. The main takeaway is that the Operator path adds cluster operation work and buys high availability only on the Enterprise tiers.
| Factor | Kubernetes Operator | Linux install |
|---|---|---|
| Plan requirement | Available on Entry, Enterprise and Enterprise Advanced, not Professional | Available on the plans you buy, including Professional; confirm feature gates with Mattermost |
| High availability eligibility | Requires Enterprise or Enterprise Advanced for the HA cluster design | HA clustering is also limited to Enterprise and Enterprise Advanced |
| File storage for HA | Shared storage on Amazon S3, an S3-compatible service or NAS mounted on each node | Shared S3, S3-compatible or NAS storage is required for any HA cluster |
| File storage for single node | Mattermost recommends an NFS volume if filestores use Kubernetes volume mounts; test other volume types | Local filesystem storage works for a single node; back it up on your own schedule |
| Database | Managed database service recommended by Mattermost for most production cloud-native deployments | Self-run PostgreSQL, including backups, patching and replica setup |
| Upgrade path | Operator-driven rollout within the cluster, plus Kubernetes control plane and node upgrades | Replace the binary and run database migrations on the host; monthly server releases and ESR tracks apply |
| Required skills | Kubernetes operation, storage classes, secrets handling, and cloud database administration | Linux administration, PostgreSQL administration, reverse proxy and TLS management |
| Licensing context | Compiled binaries under MIT; custom builds' source under AGPL v3.0; paid plans add features | Same licensing; the install method does not change which features a plan unlocks |
| Cost drivers | Cluster footprint, managed database and object storage, and the people who run the platform | Host sizing, database operations time, and the people who run the platform |
| Team size where Kubernetes pays off | Usually a platform team already running Kubernetes for several services; confirm the fit with your own workload | Often sufficient for smaller teams without an existing cluster; confirm capacity and HA needs first |
Why file storage decides whether HA is possible
A Mattermost high availability cluster cannot run on local disk. Every application node needs shared file storage, either Amazon S3, an S3-compatible service or a NAS mounted on each node. Mattermost states that local file system storage will not work correctly and risks corrupting files. Before you price the Enterprise plan that unlocks high availability, confirm with your storage team that the bucket or NAS share is reachable from every node at the same time, that it is backed up and that its latency and throughput suit uploads and previews from your largest channels. The same storage question applies whether you run the Operator or a Linux install, so settle it first.
Kubernetes adds a second decision. Mattermost recommends an NFS volume when filestores use Kubernetes volume mounts, and it notes that not all persistent volume types have been tested. If your platform team plans to back the filestore with a storage class from a cloud or on-premises CSI driver, ask Mattermost in writing whether that volume type is in its tested set, and ask your storage team how the NFS export handles permissions for the user the pods run as. Treat an untested volume type as a risk to plan around, not as a supported option. Where the Operator's storage path is not yet proven in your environment, a Linux install with shared storage avoids that dependency on Kubernetes volume behavior.
Ask for three things before committing: the list of tested persistent volume types for your Kubernetes version, the S3 or NAS configuration Mattermost expects for your node count, and a documented restore test for the file store alongside the PostgreSQL backup. Your own environment decides the answer. Run a file upload and download test from two nodes at once, then a restore into a separate namespace or host, and record the results. If any step fails or cannot be confirmed in writing, the high availability requirement is not met yet.
What each deployment is made of
Both paths run the same Mattermost server, but they assign state, redundancy and cluster operations to different parts of your stack. The cards below separate what Mattermost itself needs from what a Kubernetes cluster adds, so you can count the components you will own before you pick a path.
Linux single binary with PostgreSQL
Mattermost runs as one Go binary on a Linux host, with PostgreSQL as its database and local or mounted file storage for uploads. Your team owns the host, the operating system patches, the PostgreSQL server, backups and the reverse proxy. Confirm that your file storage is local and backed up as part of the host, since high availability later depends on moving files off the node. Mattermost's Team Edition and Entry mode run on this path without the Kubernetes plan requirement.
Operator with S3-compatible storage
Mattermost recommends its Kubernetes Operator for most Kubernetes and cloud-native production deployments, paired with S3-compatible object storage for files and a managed database service. Storage for uploads moves out of the pods, so nodes can be replaced without losing attachments. The Operator is available on the Entry, Enterprise and Enterprise Advanced plans, not on Professional, so confirm your plan before you design around it. Ask what the managed database service costs and which backup and restore tooling it provides.
High availability layer
High availability adds redundant application servers, redundant database servers and redundant load balancers. It is available only on the Enterprise and Enterprise Advanced plans, so a Professional subscription cannot run it regardless of platform. The cluster needs shared file storage on Amazon S3, an S3-compatible service or NAS mounted on each node, and local file system storage will not work correctly and risks corrupting files. Check that your storage meets that rule before you commit to a multi-node design.
Read and search replicas
Database read replicas and search replicas spread read traffic to scale concurrent users and reduce latency, while writes still go to the primary database. This layer matters once your user count and search load outgrow one primary, and it adds a second database to monitor and fail over. Ask your database provider how replica lag is measured and alerted, because a lagging replica can show stale messages. Replicas belong to the high availability design, so the same plan requirement applies.
Kubernetes control plane you run
A self-run cluster adds etcd, kube-apiserver and a TCP load balancer on port 6443 in front of the API servers, following the kubeadm high availability guide. That guide calls for at least three control plane nodes and etcd with an odd number of members, with five recommended for production. You also need an etcd backup plan using etcdctl snapshot save and a tested restore with etcdutl. Many teams avoid this work by using a managed Kubernetes service, so confirm who patches and backs up the control plane before you choose.
Secrets handling in Kubernetes
Kubernetes stores Secrets unencrypted in etcd by default, so database credentials, S3 keys and SSO client secrets are exposed to anyone who can read etcd or list Secrets through the API. Configure encryption at rest, restrict list and watch access with least-privilege RBAC, or pull secrets from an external store through the Secrets Store CSI Driver. Confirm which of these controls your cluster uses before you put production credentials in it. This responsibility does not exist on the Linux path in the same form.
How upgrades differ across the two models
Mattermost publishes a new server version in binary form on the 16th of each month, so both deployment models receive the same application code on the same schedule. Support windows matter more than the release date itself. Per the Mattermost server releases page, v12.0 was released on 2026-10-16 with support ending 2027-01-15, and v11.11 was released on 2026-09-16 with support ending 2026-12-15. The Extended Support Release v11.7 was released on 2026-05-15 with support ending 2027-05-15, and the previous ESR, v10.11, reached end of life on 2026-08-15.
- Monthly releases: New server versions arrive on the 16th of each month, which sets a predictable rhythm for test and production windows.
- Standard support window: v11.11 support ends 2026-12-15, so a team on it must move forward before that date.
- Current major line: v12.0 support ends 2027-01-15, a short window that favors teams planning frequent upgrades.
- ESR track: v11.7 carries support to 2027-05-15, which suits teams that want fewer upgrade events.
- Expired ESR: v10.11 reached end of life on 2026-08-15, so any remaining installs on that line should be scheduled for upgrade now.
Confirm with Mattermost which build and support tier applies to your plan before choosing a track, and check the release page again before each planned window.",
A Linux install runs the Mattermost binary and PostgreSQL on hosts your team manages directly. The upgrade path is a sequence of steps your own staff perform: back up the database and the file store, replace the binary, run any migrations, and restart the service. Because one host often runs the whole stack, the change window is also the outage window unless you have added a high availability cluster on the Enterprise or Enterprise Advanced plans. Your team owns the operating system patching, PostgreSQL minor and major upgrades, and the reverse proxy configuration, and none of those follow the Mattermost release calendar.
- Upgrade owner: Your staff run every step, so the runbook and rollback plan must exist before the first upgrade.
- Database coupling: PostgreSQL versions must be checked against each Mattermost release before you move either component.
- Outage scope: Without a high availability cluster, the restart window is the period users cannot reach the server.
- OS patching: Host patches and Mattermost upgrades can collide, so schedule them as separate events.
- Rollback: Keep a tested database backup and the previous binary available for every change.
Check the Mattermost upgrade notes for each target version and test them against a copy of production data before scheduling the change.",
With the Kubernetes Operator, Mattermost releases still arrive monthly, but the work splits into two tracks: the application upgrade and the cluster upgrade. The Mattermost Kubernetes deployment docs recommend the Operator with S3-compatible storage and a managed database service for most production deployments, which moves database and file durability out of the cluster. The cluster itself, however, has its own support clock. Kubernetes maintains the three most recent minor releases, and as of September 2026 those were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027). Kubernetes releases arrive about three times per year on a cycle of roughly 14 weeks.
- Two upgrade tracks: Application upgrades and cluster upgrades have separate owners, schedules and rollback plans.
- Version skew rule: kube-apiserver must be upgraded first and only one minor version at a time, before kube-controller-manager, kube-scheduler and kubelets.
- Kubelet lag: Kubelets may run up to three minor versions behind kube-apiserver, which gives room but not indefinite delay.
- Maintained minors: 1.37, 1.36 and 1.35 were the currently maintained minors as of September 2026, so plan a move onto a maintained line before one of them ends.
- Managed control planes: Some providers upgrade the control plane for you, which changes who performs the first step.
Confirm the Kubernetes version your provider supports and whether the Mattermost Operator version you run supports the target cluster minor before you start.
Running Kubernetes means your team also carries the control plane lifecycle, which can be the largest recurring effort in this comparison. A self-managed cluster needs at least three control plane nodes in a high availability layout, with a TCP load balancer in front of kube-apiserver on port 6443. The etcd datastore should have an odd number of members, and the Kubernetes documentation recommends five members in production. Each etcd member requires a backup plan, using etcdctl snapshot save for backups and etcdutl for restores, and these steps must be rehearsed before any cluster upgrade.
- Control plane topology: Choose stacked etcd on control plane nodes or an external etcd cluster, and understand which one you must upgrade and back up.
- Node count: High availability needs at least three control plane nodes, which adds hosts to patch.
- etcd backups: Take snapshots before each cluster change and test restores on a separate environment.
- Secrets handling: Secrets are stored unencrypted in etcd by default, so encryption at rest must be enabled before the upgrade plan includes it.
- Staffing: Ask who will perform cluster upgrades when the Kubernetes maintainers announce end-of-life dates.
Ask your Kubernetes provider or platform team to document their upgrade calendar and who carries each step.
Backups, monitoring and skills each model requires
This table compares what each model asks your team to back up, watch, staff and carry on call. Read it as a checklist of operating duties: the Operator adds a Kubernetes control plane and etcd to the list, while the Linux install concentrates effort on the application host, PostgreSQL and shared file storage. Confirm each item against your own environment before committing.
| Area | Kubernetes Operator with S3 and managed database | Single Linux binary with PostgreSQL |
|---|---|---|
| Backup scope | Managed database backups, S3-compatible file storage, Kubernetes manifests and Operator configuration, plus etcd state if you run the cluster yourself | PostgreSQL dumps or snapshots, the file store, and the server configuration file |
| etcd backups | Take snapshots with etcdctl snapshot save and rehearse restores with etcdutl. Confirm whether your managed Kubernetes service handles this for you | Not applicable |
| Cluster topology | Kubernetes recommends an odd number of etcd members, with five members in production, so plan for that count if you self-manage the control plane | One application host plus a database, with redundancy added only where your Mattermost plan supports it |
| Secrets handling | Kubernetes stores Secrets unencrypted in etcd by default. Confirm encryption at rest, least-privilege RBAC and any external secrets store with your platform team | Database credentials and configuration secrets kept on the host or in your secrets tool, with file permissions and access controls set by your team |
| Monitoring points | Node and pod health, control plane components, database metrics, S3 request errors, ingress and certificate expiry, plus Mattermost application metrics | Host CPU, memory and disk, PostgreSQL health and replication lag, Mattermost service status, file store capacity and TLS expiry |
| On-call exposure | Failures can sit in the cluster, the Operator, networking, storage classes or the managed database, so on-call must triage across layers | Failures mostly sit on one host, the database or the file store, which narrows triage but leaves no automatic failover unless you build it |
| Team skills | Working knowledge of Kubernetes, RBAC, persistent volumes, etcd recovery and upgrade sequencing, in addition to Mattermost administration | Linux administration, PostgreSQL operations, reverse proxy and TLS management, and Mattermost administration |
| Upgrade effort | Coordinate Kubernetes version skew rules with Mattermost releases, which ship on the 16th of each month, and test each change in a non-production cluster | Replace the binary and run database migrations on a maintenance window, with a tested rollback path |
| Who to confirm with | Your platform team, your managed Kubernetes provider and Mattermost support for supported storage types and plan entitlements | Your database administrators and Mattermost support for supported PostgreSQL versions and file storage configuration |
When the Kubernetes overhead pays off
The Operator adds a cluster to run, patch and back up, so it only pays off when that cost is already carried by a platform team or when the deployment needs controls a single Linux host cannot provide. The cards below set out the conditions that tip the decision and the checks to run before committing.
Platform staff already run clusters
If your organization already operates production Kubernetes with people on call for it, the Mattermost Operator mostly adds one more workload to a system you already maintain. If no one on your team can troubleshoot a control plane, etcd or ingress, a Linux install with PostgreSQL is easier to keep running. Ask who owns cluster upgrades and whether that team has capacity for Mattermost on top of its current services.
High availability on Enterprise plans
Mattermost high availability, with redundant application servers, database servers and load balancers, is available only on the Enterprise and Enterprise Advanced plans. The Operator is the path Mattermost recommends for most production Kubernetes deployments, and it is not offered on Professional. Confirm the plan and seat count with Mattermost before designing for HA, since the plan decides whether the Operator is available to you at all.
Fit with GitOps and cluster policy
Where cluster-wide policy already governs workloads, the Operator lets Mattermost follow the same rules as everything else. Check that the namespace meets your Pod Security Standards level, that service accounts and RBAC follow least privilege, and that Mattermost manifests live in the same GitOps repository and review process as the rest of your platform. A standalone Linux host sits outside these controls unless you build them yourself.
Small single-team deployment
For one team with modest scale and no cluster in place, a single Linux binary on PostgreSQL is usually the shorter path to a working chat service. You avoid running etcd backups, control plane upgrades and a shared storage layer for a few users. Revisit the decision if the team later needs HA, separate scaling of components, or policy enforcement across many workloads.
Air-gapped or regulated ownership
In an air-gapped or heavily regulated network, the team must document and operate every layer, including the cluster, its secrets and its images. Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest and tight RBAC must be configured and evidenced. Confirm that the Operator, its images and its S3-compatible storage can run offline in your environment, and that Enterprise Advanced air-gapped support covers your topology.
Questions buyers ask before choosing a Mattermost deployment model
Can a Linux install of Mattermost be highly available?
Yes, but only on the Enterprise or Enterprise Advanced plans, and only with shared file storage. Mattermost high availability uses redundant application servers, redundant database servers and redundant load balancers. Each node must mount shared storage, such as Amazon S3, an S3-compatible service or a NAS. Local file system storage does not work correctly in a cluster and risks corrupting files, so adding Linux hosts with local disks does not create high availability. Database read replicas and search replicas can add scale, with reads distributed across replicas and writes sent to the primary. Confirm the plan, storage layout and load balancer design against the Mattermost high availability documentation before you size the environment.
Does the Mattermost Kubernetes Operator require an Enterprise plan?
No, but it is not available on every plan. Mattermost lists its Kubernetes deployment on the Entry, Enterprise and Enterprise Advanced plans and not on Professional, so a Professional subscription cannot use this path. Entry is the free mode of Enterprise Edition. Running the Operator does not by itself provide high availability, because the cluster features that depend on a paid plan still apply. Mattermost recommends the Operator with S3-compatible storage and a managed database service for most production Kubernetes deployments. Confirm which features the Entry mode includes against the current plan documentation before you commit to a design.
What drives cost on the Linux install and the Kubernetes path?
Mattermost sells prepaid annual subscriptions based on seat licenses, and its pricing page lists no public prices, so the license line comes from a sales quote. Infrastructure and labor are separate costs that you pay directly. On the Linux path, the main costs are the hosts, PostgreSQL, the load balancer, shared storage for high availability and the staff who patch and back up the system. On the Kubernetes path, add control plane nodes, etcd backups, an ingress layer, monitoring and cluster upgrades. Ask any quote to state the seat count, plan, support tier, what is included in each plan, and which cloud resources are assumed.
How long does a Mattermost deployment take, and what does the team need?
No duration figure is supplied for this work, so the reliable answer comes from the written scope. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask the provider to list the environments, storage design, database, identity integration, testing, cutover and handover tasks, and the team members each task depends on. On the Linux path, the team needs Linux administration and PostgreSQL skills. On the Kubernetes path, it also needs cluster operations, cloud storage and database administration, and an on-call process. Ask for the assumptions the timeline depends on, such as the number of environments and the state of existing identity systems.
Can our team run a Mattermost deployment without outside help?
Many teams can, if they already have the skills for the platform they choose. The Linux path has fewer moving parts. The Kubernetes path requires cluster skills: a kubeadm high availability control plane uses at least three control plane nodes, etcd needs a backup plan and an odd number of members, and Secrets are stored unencrypted in etcd by default unless you configure encryption at rest. Kubernetes upgrades must go one minor version at a time, and each minor release receives about one year of patch support. Mattermost publishes server binaries on the 16th of each month, and v11.7 is an Extended Support Release supported until 2027-05-15. DeployOpen can plan, implement, harden, back up, upgrade, document and support the platform, and ongoing support is available as a retainer.
When does Kubernetes pay off for a Mattermost team?
Kubernetes pays off when the team already operates a cluster and can spread the platform work across existing people and tooling. No team size threshold is supplied, so ask the provider and your own platform team to test the decision against your numbers. Illustrative example: a group that already runs a cluster for other services, with staff who handle upgrades and monitoring, may find the added work for Mattermost is small. A team with one Linux administrator and no cluster experience usually finds the Linux install easier to run. Consider the number of environments, the need for multi-node high availability, your cloud standards and the cost of keeping cluster skills current.
Can we move from a Linux install to Kubernetes later, and what changes?
A move is possible, but it should be planned as a migration. File storage changes most: Mattermost recommends an NFS volume when filestores use Kubernetes volume mounts and notes that not all persistent volume types have been tested, so confirm your storage class before cutover. The database may move to a managed service, and the configuration and license must carry over. Plan DNS and TLS changes, test restores from backup and rehearse the cutover on a copy of the data. Mattermost's Kubernetes deployment documentation lists the supported storage and database options. No migration duration is supplied, so ask for a written scope with a rollback plan before work begins.
What it costs to move between the two models later
Moving from a Linux install to the Operator later is mostly a database and file storage exercise, and the cost depends on what you set up on day one. The Linux path keeps PostgreSQL on a server you manage and typically stores uploads on local disk. The Operator path expects a managed database service and S3-compatible storage. Each side has to move: the database dump and restore, the files in the filestore, and the server configuration that points at them. Local file system storage does not work for a high availability cluster, so if you ever plan to run HA, the filestore should already sit on Amazon S3, an S3-compatible service or a NAS mounted on each node. If it does, the later move is largely a database and configuration task. If it does not, you will migrate files and change the storage model at the same time, which is the harder project.
Users, teams, channels and most settings carry over with the database, but the parts that live outside it need a checklist. Confirm that the config.json values for file storage, database connection, SSO and email are reproduced in the Operator's custom resource rather than copied blindly, because the file paths and hostnames change. Plan for session and signing secrets to be moved deliberately, since a change there logs users out or breaks integrations. Mattermost's SSO and AD/LDAP settings tie to identity providers and hostnames, so test login against a staging copy before cutover. Search indexes and integrations may need rebuilding or re-registration, and you should inventory both before scheduling.
Downtime planning is the largest variable, and it is set by how much data you move and how long you can freeze writes. Plan a maintenance window that stops writes to the old server, takes a final database backup, syncs the filestore, starts the new deployment and then validates users, uploads and notifications before reopening access. Keep the old install intact until you have confirmed a clean restore and rollback path. Confirm the exact migration procedure, supported starting versions and any required upgrade steps with the Mattermost Kubernetes deployment documentation before you schedule anything, and ask for a written downtime estimate that matches your data volume.
How DeployOpen scopes and delivers a Mattermost deployment
The sequence turns a chosen Mattermost model into a written, fixed-scope plan, then a hardened deployment inside the client's own infrastructure that is documented, backed up and kept current under a support arrangement the client agrees in advance.
Confirm the deployment model and plan edition
DeployOpen reviews the team size, Kubernetes or Linux preference, identity provider, compliance obligations and whether high availability or air-gapped operation is required. The client confirms the Mattermost plan with Mattermost, since the Kubernetes deployment is available on Entry, Enterprise and Enterprise Advanced but not on Professional, and high availability requires Enterprise or Enterprise Advanced. The step is done when the model and plan are recorded in a written scope draft that the client has reviewed.
Agree scope, deliverables and timelines in writing
DeployOpen turns the draft into a fixed-scope proposal listing deliverables, responsibilities, client-provided items such as cloud accounts, DNS, certificates and a licensed Mattermost subscription, and the timeline agreed for each phase. Work does not start until both parties sign. DeployOpen does not publish a price list, so the written scope is the basis for the quote. The step closes with a signed scope document.
Design storage, database and network layout
For the Operator path, DeployOpen designs the S3-compatible object storage, the managed database service and the Kubernetes volumes, following Mattermost guidance that an NFS volume is recommended when filestores use Kubernetes volume mounts and that not all persistent volume types have been tested. For the Linux path, the design covers PostgreSQL and shared file storage for any high availability cluster, since local file storage will not work correctly across nodes. The step closes with an architecture document the client approves.
Implement and harden inside the client environment
DeployOpen installs Mattermost in the client's cloud account, data center or air-gapped network, then applies hardening: secrets handling, network policies, pod security settings for Kubernetes, least-privilege access to the database and storage, and encryption at rest where the platform supports it. For Kubernetes, Secrets are unencrypted in etcd by default, so encryption at rest and restricted access are configured explicitly. The step closes with a test report and a hardening checklist signed off by the client's security owner.
Integrate identity and storage
DeployOpen connects SSO through SAML, OIDC or OAuth and AD/LDAP user sync where the chosen plan includes them, then verifies login, deprovisioning and role mapping with test accounts. Storage and database connections are tested for failover behavior and read replica use where the plan supports it. The step closes when a test matrix for identity and storage has passed and the results are filed with the scope.
Document, back up and rehearse recovery
DeployOpen delivers runbooks for installation, configuration, upgrades, backups and restore. Backups cover the database, file storage and, for Kubernetes, the etcd snapshot process and the Helm or Operator configuration. A restore is rehearsed in a separate environment so the client knows the recovery steps work. The step closes with a documented restore test and a signed handover.
Plan upgrades and provide ongoing support
Mattermost publishes server versions on the 16th of each month and offers Extended Support Releases with fixed end dates, so DeployOpen agrees an upgrade calendar that matches the client's support window. Kubernetes adds its own cycle and version skew rules, which the upgrade plan follows. Ongoing support, upgrades and continuous testing are available as retainers, and their scope, response expectations and fees are set out in a separate written agreement. The step closes when the first upgrade has been rehearsed and the retainer terms, if any, are signed.
