Why teams run Mattermost on Kubernetes and what makes it harder than it looks
Kubernetes is a sound place to run Mattermost when your platform or security team already operates clusters and wants messaging managed with the same deployment, policy and upgrade habits as other services. What it changes is mostly the packaging and the surrounding infrastructure, not the application. Mattermost is built in Go and React and runs as a single Linux server binary with PostgreSQL as its database, so the cluster does not make the product behave differently. It makes you responsible for how that binary is packaged, where its state lives, and how traffic reaches it. That distinction is the source of most of the difficulty. The application itself is straightforward to start. The hard parts sit around it. The first is stateful dependencies: PostgreSQL is kept outside the cluster in most designs, so the team must decide whether it runs in a managed service, a database platform the organization already operates, or a separate environment, and how backups and failover are handled there. The second is file storage. Mattermost high availability requires 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. Pods that scale out must all see the same storage, so storage choice is a design decision made before the first replica starts. The third hard part is TLS termination and the path into the cluster. Decide where certificates are issued, renewed and stored, which ingress or load balancer terminates TLS, and how WebSocket connections used by the client are passed through. Confirm these behaviors with your ingress controller and the Mattermost deployment documentation for your release, since they affect every user connection. The fourth is upgrade sequencing. Mattermost releases a new server version in binary form on the 16th of each month, and Extended Support Releases follow a longer cycle. Your cluster rollout must account for database migrations, plugin compatibility and the order in which replicas are replaced, and the upgrade pattern on Kubernetes differs from a single Linux host. Mattermost can be deployed on Kubernetes, on Linux or in containers, so the choice should follow your operating model rather than the feature list. Features such as SSO, high availability and air-gapped operation depend on the plan you hold, not on the platform you choose. Ask whether your team already runs stateful workloads on Kubernetes, who is on call for the database and storage tiers, and whether your release cadence can absorb monthly upgrades. If those answers are unclear, a Linux or container deployment may fit better for the first rollout. Before you commit, confirm with Mattermost which deployment method and plan your requirements need, and document who owns PostgreSQL, file storage, certificates and upgrades. A short written inventory of these owners usually shows whether Kubernetes adds operational value for your organization or simply adds another layer to maintain.
Which components make up a Mattermost Kubernetes deployment
A Mattermost Kubernetes deployment is a set of application pods that depend on components outside the cluster and components inside it. Each one has a different owner, and each must survive a different kind of failure, so the ownership and recovery questions should be settled before the first install.
Mattermost application pods
These pods run the Mattermost server, which is delivered as a single Linux binary. They are stateless in the sense that conversations and files live in PostgreSQL and the shared file store, so pods can be replaced without losing data. The platform team typically owns them, including resource requests, probes, rollout strategy and the replica count. Check how the packaging option you choose handles configuration changes and rolling restarts, and confirm the current packaging approach in Mattermost documentation for your chosen server version.
External PostgreSQL primary and replicas
PostgreSQL is the system of record for messages, channels, users and configuration, and it runs outside the application pods. The database team typically owns the primary, backups, failover and any read replicas used to spread read traffic. The cluster must survive a primary failure without losing committed writes, and the team should test how application pods reconnect during a failover. Confirm the supported PostgreSQL versions and replica settings for your Mattermost server version.
Shared file store
Uploaded files and attachments must be available to every application pod, so they belong in Amazon S3, an S3-compatible service or a NAS mounted consistently on each node. The storage team typically owns capacity, retention, encryption and access policy. Local or pod-scoped storage is not a valid substitute for a shared store in a multi-replica deployment, because files can become unavailable or corrupt. Confirm the file store requirements for your server version before sizing the bucket or volume.
Ingress controller and TLS certificates
The ingress controller routes user traffic to the Mattermost service and terminates TLS, so it sits in front of every client connection. The platform or network team typically owns the controller, the DNS record and the certificate lifecycle. Certificates must be renewed automatically or on a tracked schedule, and WebSocket connections must pass through the controller without being dropped. Check the proxy and timeout settings against Mattermost guidance before go-live.
Secrets and configuration
Database credentials, file store keys, SMTP settings, and the Mattermost configuration itself must reach the pods without being stored in plain manifests. The platform team typically owns the secret store, the config mapping and the process for rotating credentials. Changes to configuration should be versioned and tested in a non-production namespace first. Confirm which settings the server reads from environment variables and which must be managed through the admin console or configuration file.
Search and read replica settings
Read replicas and search replicas distribute query load away from the primary database, and the application must be configured to send reads and writes to the right endpoints. The database team and the Mattermost administrator share ownership of these settings. The risk is stale reads or misrouted queries after a failover, so the team should verify replica lag handling and search behavior during failure tests. Confirm the replica and search configuration against the high availability guidance for your server version.
Which packaging and dependency choices shape the Kubernetes design
This table compares the packaging, database, file storage, ingress and license choices that set the shape of a Mattermost Kubernetes deployment. Read each row for the situation where the option fits and the ongoing work it places on your team. The main takeaway is that a multi-server design needs shared file storage and an Enterprise or Enterprise Advanced license, so these choices should be settled before manifests are written.
| Option | When it fits | What it costs you operationally |
|---|---|---|
| Packaging: community Helm chart | Your team wants a maintained starting point and is comfortable reviewing and pinning chart values. | Your team owns chart version pinning, value overrides and a review of each Mattermost monthly release before rollout. |
| Packaging: self-maintained manifests | You need direct control over every object and have Kubernetes staff to maintain them. | Image tags, probes, configuration and upgrade steps are written and tested by your team, so this effort recurs with each release. |
| Packaging: operator already in use | Your platform team already runs an operator and standardizes on its lifecycle model. | Confirm the operator supports the Mattermost settings you need, then track the operator's own upgrade cycle alongside Mattermost's. |
| Database: external managed PostgreSQL | You want backups, patching and failover handled by a database service your organization already operates. | You pay the managed service fees and manage network access, credentials and connection limits between the cluster and the database. |
| Database: in-cluster PostgreSQL | A pilot or non-production environment where separate database hosting is not justified. | Your team owns storage classes, backups, restore testing and database upgrades inside the cluster. |
| File storage: S3 or S3-compatible | Several application servers need shared file storage, which the high availability cluster requirements call for. | You provision and secure the bucket or object service, manage access keys, and confirm with Mattermost that your S3-compatible service is supported. |
| File storage: NAS mount | Your organization already runs NAS and it can be mounted consistently on every node. | Local file system storage is not safe for a cluster and risks file corruption, so your team must maintain the mount on each node and monitor it. |
| Ingress: existing controller | The cluster already has an ingress controller and certificate process used by other services. | Your team confirms WebSocket, upload and TLS settings with the security team and reuses the existing renewal process. |
| License: multiple application servers | You run more than one application server for redundancy or capacity. | High availability clustering is available only on Enterprise and Enterprise Advanced. Mattermost's pricing page lists no public prices, so request a quote from sales with your node and seat counts. |
How to build a Mattermost Kubernetes deployment in sequence
This sequence takes a team from a confirmed server version to a multi-replica Mattermost deployment on Kubernetes. Each step closes with a check, so the team knows the layer beneath it works before adding the next one.
Confirm the server version and release channel
Before any manifest is applied, the platform owner checks the Mattermost server releases page and chooses either the monthly release train or an Extended Support Release (ESR). Monthly releases ship on the 16th of each month, and the page lists each version's support end date, so the team can plan its upgrade cadence from the start. Record the chosen version and channel in the deployment notes and confirm the image tag matches it. Done when the version, channel and support end date are written down and approved by the application owner.
Provision external PostgreSQL and test connectivity
Mattermost stores its data in PostgreSQL, so the database is provisioned outside the cluster, in a managed service or a separately operated server. The platform team creates a database and a dedicated role, then confirms that a test pod in the target namespace can reach the database host and port through the network policy in place. Confirm the chosen PostgreSQL major version against the Mattermost server documentation for the version selected in the previous step. Done when a connection test from the namespace succeeds and the server's startup logs show a successful database connection.
Provision shared file storage for all pods
Mattermost stores uploaded files outside the database, so every pod must read and write the same storage. Use Amazon S3, an S3-compatible service or a network file share that every node can mount, as the Mattermost high availability documentation describes. Local file system storage on a node does not work correctly across multiple nodes and risks corrupting files, so it is not used for a multi-node setup. Done when a test file uploaded through one pod can be downloaded through a second pod, which confirms that the storage is genuinely shared.
Create secrets for credentials and the license
The platform team stores the database credentials, the file storage access keys and the Mattermost license as Kubernetes secrets in the target namespace, so none of them appear in manifests or version control. The Kubernetes secrets should be encrypted at rest according to the cluster's configuration, and access should be limited to the service account that runs Mattermost. Confirm the license file or key is valid for the plan being deployed before it is referenced. Done when the pod spec references each secret by name and a test pod can read the values it needs without exposing them in logs.
Apply the packaging with one replica
The team applies the chosen Mattermost packaging, such as a maintained Helm chart or a manifest set, with the replica count set to one. Keeping one replica lets the team confirm the application starts, connects to PostgreSQL and file storage, and serves the login page before any scaling is introduced. Review the rendered manifests for the image tag, the secret references and the storage configuration. Done when the single pod reports ready, its logs show a successful database connection, and the server's health check returns a healthy response.
Configure ingress and TLS termination
The platform team creates an ingress resource that routes the chosen hostname to the Mattermost service and terminates TLS with a certificate issued for that name. The Mattermost site URL setting must match the public hostname exactly, or links, redirects and integrations will point to the wrong address. Confirm the certificate chain is trusted by the client browsers the organization supports. Done when the site loads over HTTPS in a browser from outside the cluster, the certificate details show the expected hostname, and the sign-in page renders without mixed content warnings.
Scale replicas after license and storage checks
Only after the license is confirmed for a cluster deployment and the shared storage test has passed does the team increase the replica count. Scaling beyond one application server is part of Mattermost high availability, which the pricing page lists under the Enterprise plan and above, so the team confirms the license tier with the vendor or account contact first. Increase replicas in small steps, then check that each new pod becomes ready and that a message posted through one pod appears for a user connected to another. Done when all replicas are ready, cross-pod messaging and file access work, and the license status shows the expected cluster capability.
What drives effort and cost in a Kubernetes rollout
This table lists the factors that change how much work a Mattermost Kubernetes rollout takes, with a note on how to keep each one under control. No effort figures are given here, so use the rows as a checklist for scoping a fixed-scope quote rather than as a estimate. Items marked as quote inputs should be stated in writing before work starts.
| Driver | How it raises effort | How to keep it down |
|---|---|---|
| Number of users and concurrent sessions | Higher concurrency drives replica count, database sizing and load balancer capacity, and it raises the need for read and search replicas. High availability is only available on Enterprise and Enterprise Advanced plans. | Confirm peak concurrent users and growth expectations early, and size for the actual peak rather than total headcount. Decide whether high availability is required before choosing the architecture. |
| Data volume and file uploads | Large file stores enlarge object storage, backup scope and restore testing. A high availability cluster needs shared storage on S3, an S3-compatible service or NAS on every node. | Agree retention rules and file size limits before rollout. Use managed or S3-compatible object storage and include restore tests in the quoted scope. |
| Number of environments | Separate development, test and production environments, especially on separate clusters, double the manifests, secrets, ingress and upgrade rehearsals that must be maintained. | Use one set of versioned manifests or Helm values with per-environment overrides. Confirm in the quote which environments are included and which are client-run. |
| Identity integration | SSO through SAML, OpenID Connect or AD/LDAP sync requires identity provider configuration, group mapping, test accounts and deprovisioning checks. SSO and AD/LDAP sync are included from the Professional plan, according to the Mattermost pricing page. | Confirm the identity provider and its supported protocol early. Define group mapping and offboarding rules in writing, and check the current Mattermost documentation for the chosen method. |
| Integrations and custom plugins | Each plugin, webhook or bot must be tested against every server upgrade, and custom plugins need their own build, signing and maintenance path. | Keep an inventory of integrations with owners. Limit custom plugins to what is needed and make plugin testing part of each upgrade cycle. |
| Compliance requirements | Frameworks add evidence collection, audit logging, network policy, encryption and retention controls. DeployOpen prepares evidence for assessments but does not issue audit reports or certifications. FIPS 140-3 compliance is listed for Enterprise plans. | Ask the auditor or compliance lead for the exact evidence list before design starts. Map each control to a configuration item so evidence is produced during the build, not afterward. |
| Existing cluster standards | A cluster with GitOps workflows, policy engines or a secret management platform requires the Mattermost manifests to follow those patterns, which adds review and integration work. Policy engines may block default container settings. | Share the cluster standards, admission policies and secret store details at scoping. Reuse the existing GitOps repository and pipeline rather than building parallel tooling. |
How the Kubernetes design changes across single node, HA and air-gapped setups
A single application pod with external PostgreSQL is the simplest Kubernetes shape for a pilot. One Deployment runs the Mattermost server, the database sits outside the cluster, and most of the design effort goes into getting the basics right before users arrive. With no second replica, a node failure or rolling restart interrupts service, which is acceptable for a pilot but not for daily operations.
- One replica: a single Deployment with one pod, so there is no session sharing or cross-pod routing to design.
- External PostgreSQL: the database runs as a separately operated service with backups, and credentials live in Kubernetes secrets rather than in the image.
- File storage: a persistent volume is workable at pilot size, but confirm the storage class and file path settings match your server configuration. The high availability topic explains why shared storage becomes necessary later.
- Ingress and TLS: one ingress with a certificate, configured the same way the production design will use.
- Upgrade path: plan each upgrade as a maintenance window, since no other replica keeps service running during the swap.
Check that the pilot layout can move to a multi-replica design without rebuilding the database or file storage, and confirm your license plan covers the features you intend to test.
Running several application pods turns the server into a cluster, which changes how storage, database traffic and scheduling are designed. Mattermost lists high availability clustering on the Enterprise and Enterprise Advanced plans, and its high availability documentation requires shared file storage on every node. The cluster design itself is covered in the high availability topic.
- License first: confirm Enterprise or Enterprise Advanced entitlement before you size the cluster or write the Kubernetes manifests.
- Shared object storage: replace local volumes with Amazon S3, an S3-compatible service or NAS mounted on every node, because local file system storage will not work correctly and risks corrupting files.
- Read and search replicas: reads are distributed across replicas while writes go to the primary database, so connection settings and any database proxies must reflect that split.
- Pod spreading: you set anti-affinity, topology spread and disruption budgets yourself so that replicas do not land on the same node or zone.
- Routing behavior: confirm in the documentation for your version whether the ingress needs session affinity or other routing settings for multiple pods.
Confirm the storage endpoint, replica topology and license entitlement in writing before the cluster is scoped, since each one changes the Kubernetes objects you build.
In an air-gapped cluster, nodes cannot pull images, charts or updates from public registries, so the design centers on mirroring everything into the enclave before anything runs. Mattermost lists air-gapped deployment on the Enterprise Advanced plan. The offline install and update procedure is covered in the air-gapped deployment topic.
- Internal registry: mirror the server image and every companion image into a registry the cluster can reach, and set image pull policies to use only that registry.
- Chart and manifest bundles: store Helm charts or manifests inside the enclave, versioned so that each chart points to the image tags it was tested with.
- No pull-based updates: GitOps controllers and automatic image updaters that reach outside the enclave cannot be used, so every upgrade arrives as a transferred package.
- Plugin and notification review: plugins and push notifications that depend on outbound services need checking before go-live, because they may not work offline.
- Internal dependencies: PostgreSQL, object storage and certificates must also run inside the enclave, with certificates issued by an internal certificate authority.
Test a full mirror-and-upgrade cycle in a staging enclave before production, and confirm with Mattermost which images and plugins your chosen version requires.
A compliance-oriented design changes the image choice and the evidence the team keeps. Mattermost lists FIPS 140-3 compliance on the Enterprise plan, and its migration documentation covers moving to FIPS-compliant images. Whether a FIPS-compliant image exists for the exact version and edition you plan to run must be confirmed with Mattermost before the design is locked.
- Image availability: confirm that a FIPS-compliant image is published for your target version, since availability can differ between releases.
- Plan entitlement: FIPS 140-3 compliance is listed on the Enterprise plan, so check it against your contract rather than assuming it follows from the edition name.
- Image provenance: record image digests, source registry and vulnerability scan results so assessors can trace what ran in production.
- Configuration baseline: keep manifests and Helm values under version control so every change to the cluster leaves a reviewable trail.
- Assessor role: DeployOpen prepares controls and evidence, while independent auditors and certification bodies decide any assessment outcome.
Ask Mattermost to confirm FIPS-compliant image availability in writing for your target version before you size the cluster or fix the upgrade plan.
How upgrades on Kubernetes differ from Linux and Docker installs
On Kubernetes, an upgrade is a change to what the cluster runs. On a Linux host, you replace the server binary and restart one service. On Kubernetes, you change the image tag or Helm chart version in the Mattermost Deployment, and the controller replaces pods across the replica set. Mattermost releases a new server version in binary form on the 16th of each month. Your team then decides which container image or chart value carries that binary into the cluster, so the running version is whatever tag your manifests or values specify. Record that tag in version control and treat it as the single source of truth for what is deployed.
Three areas matter more in a cluster than on a single host. First, database migration timing: the new pods run schema migrations against the shared PostgreSQL database during rollout, while old pods may still be serving traffic. Confirm in the release notes whether the migration is compatible with the previous version and whether it is expected to run for a long time. Second, rolling update settings: maxSurge and maxUnavailable control how many old and new pods coexist, and the readiness probe decides when a new pod receives traffic. Third, the rollback path: Kubernetes can revert the Deployment to the previous ReplicaSet, but that does not undo a database migration, so the rollback plan must include a verified database backup and a check on whether the previous version can still run against the migrated schema.
Your release choice shapes how often you run these steps. Mattermost v11.7 is an Extended Support Release (ESR), released on 2026-05-15 with support ending 2027-05-15. Mattermost v11.11 was released on 2026-09-16 with support ending 2026-12-15. As an illustrative case, a team pinned to an ESR line plans fewer upgrades per year than a team that moves to each monthly release, but it must still schedule the move to the next ESR before support ends. Support dates change as new releases ship, so check the current support dates on the Mattermost server releases page before you set an upgrade calendar or a support commitment.
Compared with a Linux or Docker install, a cluster upgrade also needs a clear view of user-facing behavior during pod replacement. Active WebSocket connections may drop when pods are replaced, and clients reconnect to whichever pod is ready. Confirm with your ingress controller and load balancer settings how long connections stay open during rollout, and whether session stickiness affects reconnection. Run the first upgrade in a staging cluster built from the same manifests and database snapshot as production, and record the time each step takes so the production change window is based on measured results rather than estimates.
Upgrade cadence, the choice between monthly releases and ESR lines for your program, and plugin testing before each change are covered in the Mattermost upgrades and support topic. This section sets out the Kubernetes-specific mechanics you need to understand first. Before the first production upgrade, your team should have a written runbook that names the image tag, the migration check, the rolling update settings, the backup and restore steps, and the person who authorizes a rollback.
How to secure Mattermost on Kubernetes without weakening the cluster
Mattermost on Kubernetes inherits the cluster's trust boundaries, so its secrets, traffic, pod permissions and operator access need to be set deliberately. The controls below cover the platform layer, and each one is something a reviewer can check in the running cluster.
Keep secrets out of manifests and Git
Database credentials, object storage keys and Mattermost license material should live in the cluster secret store or an external vault, with the manifests referencing them by name. Check that no plain values appear in Helm values, Kustomize overlays or Git history, and confirm how secrets rotate without a manual edit to the deployment. Ask your team who can create or change these secrets and how those changes are logged.
Terminate TLS at the ingress
Mattermost clients connect over HTTPS through the ingress controller, so certificates, cipher settings and redirects from plain HTTP are enforced there. Confirm who issues and renews certificates, whether renewal is automated, and what happens to WebSocket connections during a renewal or controller restart. Also confirm that the Mattermost site URL matches the certificate name, since mismatches cause client failures that teams often mistake for network faults.
Restrict traffic with network policies
Network policies should allow Mattermost pods to reach only the PostgreSQL endpoint, the object storage endpoint and the ingress path they need, and deny other east-west traffic by default. Test the policy with the cluster's actual network plugin, because some plugins do not enforce policies at all. Note that egress to external services such as SMTP, SSO providers and push notification endpoints must be listed explicitly, or it will fail silently after go-live.
Apply restricted pod security settings
Run Mattermost containers as a non-root user, disallow privilege escalation, drop unneeded Linux capabilities and refuse privileged containers. Set a read-only root file system where the image and any plugins support it, and mount writable paths explicitly. Confirm these settings against the namespace's pod security admission level, and test a canary deployment before enforcement so that an admission failure does not block an upgrade window.
Limit service exposure
Expose only the Mattermost service through the ingress, and keep the database, search components and any admin endpoints on internal cluster addresses. Review whether NodePort or LoadBalancer services exist for the application, and remove them if they were created during testing. Ask the team to confirm which metrics or debugging ports are reachable from other namespaces, since these are a common gap in otherwise restricted clusters.
Scope RBAC for secrets and pod access
Limit which users and service accounts can read secrets in the Mattermost namespace, and restrict the exec and port-forward permissions that allow shell access into running pods. Operators who troubleshoot Mattermost need a documented break-glass path, and that path should be logged. Review role bindings after each staffing change, and confirm that the Mattermost service account has only the permissions its workloads need.
How to test that the Mattermost cluster works and fails safely
Test the Mattermost Kubernetes deployment in a fixed order: first prove it serves traffic correctly, then prove shared state and data paths behave under normal use, then prove it survives controlled failures and can be rolled back. Each step has a clear pass condition, and a failed step should stop the sequence until the cause is understood. Agree the test plan, the test window and the owner of each check before the first pod is restarted, so the results can be read later by the team that runs the platform.
Start with the basics. Confirm that every application pod reports ready through its readiness check and that the pods are not restarting in a loop. Then request the site through the ingress from outside the cluster and confirm the certificate chain is valid, the hostname matches, and plain HTTP redirects to HTTPS. Check the ingress controller and TLS termination settings against your own standard, because the reverse proxy and certificate handling are where most first-day faults appear. Record the exact certificate, hostname and ingress resource names so the check can be repeated after every upgrade.
Next, prove shared storage. Upload a file through a session that lands on one pod, then download the same file through a session that is served by a different pod. The file must open with the same content and checksum. Run the same check for an image attachment, since preview generation is a common place where a pod writes locally. Confirm that the file store is the S3-compatible service, S3 bucket or NAS mount you configured, not a path inside the container. Mattermost's high availability documentation states that local file system storage will not work correctly in a clustered setup and risks corrupting files, so treat any local write as a failed test.
Then confirm database paths. Check in the Mattermost system console and in server logs that the application connects to the primary PostgreSQL database for writes. If you configured read replicas, confirm the replica endpoints are listed and that read traffic reaches them. Failure modes to test here are a stale replica serving reads after a write, and a replica that is configured but never used. For a stale replica, post a message, then read the channel from a session routed to the replica and confirm the message appears within the lag you have agreed to accept. If replication lag is not measured by your database team, ask them to supply the figure before you set a pass threshold.
Finish with controlled failures and a rollback drill, both in the test window and scoped to this deployment only. Restart one application pod and then drain one node, and check that logged-in sessions stay valid or re-authenticate cleanly, and that messages sent during the restart are delivered and not lost or duplicated. Force a database connection failure by blocking the application's route to PostgreSQL, and confirm the application reports the fault in the UI and logs without corrupting data. For the upgrade path, rehearse a rollback on a non-production cluster that has a copy of the database and the same storage configuration. Pay attention to a half-finished migration after an upgrade: if a new server version fails partway through schema changes, the rollback must restore a consistent database, not just older images. Keep the results in a dated report with each check, its evidence and the decision taken.
What to monitor, back up, upgrade and document after go-live
Go-live starts the operating work for a Mattermost Kubernetes deployment. The four areas below depend on each other: monitoring shows when something is failing, backups define what can be recovered, upgrades change the running system, and documentation lets someone other than the builder respond.
Monitor the early failure signals
Monitor the signals that show Mattermost is degrading before users report it. Watch pod restarts and readiness failures for each deployment, because repeated restarts often point to database connection exhaustion or a faulty configuration change. Track ingress certificate expiry with alerts well ahead of the expiry date, since an expired certificate stops every client at once. Watch database connection counts and storage health for both the PostgreSQL service and the shared file store. Confirm alert routing and who responds outside business hours before go-live.
Back up and test restores
Back up the PostgreSQL database on a schedule and test restores into a separate namespace. A backup that has never been restored is unverified. Object storage holding uploaded files needs versioning or a replication policy so that deleted or overwritten objects can be recovered. Restores must work inside the same Kubernetes design, so record the chart or manifest version, secret names and storage class alongside each backup. Confirm backup frequency and retention requirements with your compliance owner before setting them.
Plan upgrades and rollback
Choose the release channel before the first production upgrade. Mattermost releases server versions in binary form on the 16th of each month, while an Extended Support Release such as v11.7, supported until 2027-05-15, offers a longer support window with fewer version changes. Build an upgrade calendar that places a staging upgrade ahead of each production window, and test plugins and custom integrations on the target version first. Write a rollback plan that names the database restore point and the previous image tag, and rehearse it once before it is needed.
Document the deployed state
Keep a current record of the deployed state, including the chart or manifest version, the values files for each environment, and the secret inventory listed by name only, never by value. Record where each secret is stored and which workload reads it. Write runbooks for pod restarts, certificate renewal, database failover, restores and upgrades. Assign a named owner to each component, including ingress, the database, file storage and the Mattermost application, and review those assignments whenever staff change roles.
What buyers ask before choosing a Mattermost Kubernetes partner
Can our own team run a Mattermost Kubernetes deployment without a partner?
Yes, if your team already runs Kubernetes in production, has experience with PostgreSQL and object storage, and can own a deployment pipeline. Most teams find the harder work lies in the surrounding decisions: ingress and TLS, external PostgreSQL sizing, shared file storage, and how configuration changes are tested before they reach production. Mattermost's deployment planning documentation lists Kubernetes as one supported method, so the main question is usually capacity and ownership. Ask who will receive the alerts, who patches the cluster, and who approves a change to the Mattermost configuration. If those answers are unclear, a fixed-scope engagement can cover the build, handover and documentation, and your team operates the platform afterward.
What does a Mattermost Kubernetes rollout need from our team?
Expect to name owners for four areas before work starts:
- Cluster access: a namespace, role-based access, and an ingress controller your platform team supports.
- Database owner: the person who provisions external PostgreSQL and agrees on backup, sizing and failover.
- Storage owner: the team that provides Amazon S3, an S3-compatible service or NAS for shared file storage.
- Named approver: one person who signs off the license, the plan and the seat count.
You will also need DNS and certificate ownership, an identity provider administrator if SSO is in scope, and a reviewer for security settings. Confirm these owners, their availability during testing, and their escalation contacts in the written scope so that delays in one area do not stall the others.
What drives the cost of a Mattermost Kubernetes deployment?
Mattermost sells Professional, Enterprise and Enterprise Advanced subscriptions as prepaid annual plans based on seat licenses, and its pricing page lists no public prices, so the subscription is quoted separately. The main drivers are the plan and seat count, expected concurrent users, storage volume and retention, the number of environments (such as development, staging and production), the integrations and plugins that need testing, and compliance requirements such as FIPS 140-3 or air-gapped operation. The subscription recurs each year. The implementation, testing and handover are usually one-time costs, while cloud infrastructure, database and storage services, and support recur. Ask for the quote to list each of these items separately, with what is included and what is excluded.
How long does a Mattermost Kubernetes rollout take, and what sets the timeline?
The timeline depends on scope, and DeployOpen agrees the scope, deliverables and timelines in writing before work starts. The biggest factors are the readiness of dependencies: cluster availability, PostgreSQL provisioning, shared file storage, DNS and certificates, and identity provider access for SSO. Testing also sets the pace, including load testing, plugin and integration checks, and a security review. Approval cycles for the license and change windows matter as well. Ask for a schedule that lists each dependency, the party responsible for it, and the date it must be ready. Milestones tied to those dependencies are more reliable than a single end date.
Does high availability for Mattermost on Kubernetes require the Enterprise plan?
Yes. Mattermost's pricing page lists high availability clustering as an Enterprise plan feature, and its high availability documentation states that the feature is available only on the Enterprise and Enterprise Advanced plans. A high availability design also needs redundant application servers, redundant database servers and redundant load balancers, plus shared file storage on Amazon S3, an S3-compatible service or NAS mounted on each node. Local file system storage will not work correctly and risks corrupting files. Read and search replicas can be added to scale concurrent users. Confirm the current plan terms with Mattermost before you commit, because plan features can change.
How are Mattermost upgrades handled on Kubernetes after go-live?
Mattermost releases a new server version in binary form on the 16th of each month, so you choose between the monthly release train and an Extended Support Release. Mattermost v11.7 is an Extended Support Release with support ending 2027-05-15, according to the server releases page. On Kubernetes, an upgrade means changing the image version, checking plugin compatibility, running database migrations, and performing a rolling update with a tested rollback path. Each step should run first in staging with a copy of production data. Ongoing support, upgrade planning and continuous testing can be contracted as a retainer, and the scope of that retainer should be written down before go-live.
How DeployOpen scopes, builds and hands over Mattermost on Kubernetes
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Mattermost on Kubernetes, that means a written scope first, then a build in your environment, then a handover your own team can run.
How we scope
- The written scope lists the cluster, namespaces, manifests or Helm values, ingress, and TLS approach agreed before work starts.
- External PostgreSQL and object or file storage are defined in scope, including who provisions and owns each service.
- Identity, team and channel structure, and integrations are listed as in or out of scope so the boundary is explicit.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.
How we build
- Manifests or chart values are built for your cluster and version-controlled in a repository your team owns.
- Replica counts, resource requests, health probes and persistent storage are configured against the scope agreed with you.
- Ingress and TLS are set up at the reverse proxy or ingress layer, and certificate handling is tested end to end.
- Build steps are tested in a non-production cluster before any change reaches production.
How we hand over
- Documentation covers the deployed architecture, configuration, secrets handling and the steps to scale or roll back.
- An upgrade runbook explains how the monthly server release or an Extended Support Release is applied and tested in your cluster.
- Your staff are walked through routine operations, monitoring checks, backup and restore for the database and files.
- Acceptance tests are run against the criteria in the written scope, and the results are delivered with the documentation.
How we support
- Support after go-live can be set up as a retainer, covering upgrades, patching, and troubleshooting within the agreed scope.
- Upgrades are planned against Mattermost's release dates, and plugin compatibility is checked before each upgrade.
- Clustered or high-availability designs need a plan and license confirmed with Mattermost, which we help you verify before build.
- Confirm with Mattermost which plan your required features need, such as SSO, high availability or air-gapped deployment, before scoping.
