What an air-gapped Mattermost deployment involves
An air-gapped Mattermost deployment is needed when the server must run in an enclave with no outbound internet access, such as classified, regulated or segmented networks. Before planning, confirm the edition: Mattermost's pricing page places air-gapped deployment in the Enterprise Advanced plan, so the subscription decision comes before the architecture work. Confirm the current plan terms directly with Mattermost sales, since the pricing page lists no public prices.
The core system is a single Linux binary backed by PostgreSQL, which keeps the component list short. The harder part is that everything around the binary must come from inside the enclave. There are no public package repositories, no plugin marketplace reachable from the server, and no direct license or update checks. Every operating system package, database component, plugin, container image if used, and each server upgrade has to be obtained outside, verified, and moved in through your own transfer process.
Plan the transfer pipeline as a controlled process, not an occasional copy. Decide who downloads artifacts, how checksums are verified, where the approved copies are stored inside the enclave, and how changes are logged. Upgrades add a second dependency: you must confirm that the target server release, the database version and each installed plugin work together before the package crosses the boundary. Mattermost publishes server releases on a monthly cadence, so the upgrade calendar must account for transfer and testing time.
This section covers only the offline path. General installation, SSO, high availability and Kubernetes each have their own pages, and the decisions there still apply inside the enclave. Ask Mattermost and your security team to confirm which steps, dependencies and license behaviors apply to your exact edition and network design before you commit to a scope.
Components and settings in an enclave
The air-gapped starting point is documented in the server deployment planning guide. Use these cards to build your internal dependency list, then confirm each item against the documentation for your chosen Mattermost version.
Server binary and plugins
A connected install normally pulls the server binary and plugin bundles from vendor channels. In an enclave, your team must stage the Linux binary, the plugin packages and their checksums in an internal repository before installation. Choose your release track first, since monthly releases ship on the 16th and Extended Support Release v11.7 is supported until 2027-05-15. Confirm each plugin's compatibility with that server version.
PostgreSQL database
Mattermost runs on PostgreSQL, and the database holds the messages, channels and user records your team relies on. Inside the enclave, you provide the PostgreSQL service, its operating system packages and its patch cycle, because no vendor-hosted database is assumed. Confirm the supported PostgreSQL major versions for your release, stage matching packages offline, and test restore procedures inside the network.
Reverse proxy and TLS certificates
Users reach Mattermost through a reverse proxy that your team operates inside the enclave. Certificates must come from an internal certificate authority, so clients need to trust that authority and public validation methods will not be available. Stage proxy packages, certificate chains and renewal tooling offline, and confirm the proxy and WebSocket settings in the documentation for your version.
File storage backend
Uploaded files are stored outside the database, so you must decide where they live before installation. A high availability cluster needs shared storage on Amazon S3, an S3-compatible service or a NAS mounted on every node, because local file system storage will not work correctly and risks corrupting files. Confirm which storage service your enclave provides and whether your topology supports it.
License and plan entitlement
Mattermost's pricing page lists air-gapped deployment under the Enterprise Advanced plan, so confirm your entitlement before the design is fixed. Subscriptions are prepaid annual plans based on seat licenses. Ask the vendor how license files are issued, renewed and applied when the server cannot reach the internet, and how seat counts are reported from inside the enclave.
Mail relay for notifications
Notification emails leave the Mattermost server through an SMTP relay. Connected installs often rely on an external provider, so the enclave needs an internal relay that accepts mail from the Mattermost host and delivers it to recipients on the internal network. Confirm the SMTP settings and any notification or push service dependency in the current documentation, then test delivery with a sample user before go-live.
Key decisions and trade-offs
This table compares the main Mattermost air-gapped choices by when each option fits and what it asks of operations and re-testing.
| Decision | When the option fits | Operational effort and re-testing |
|---|---|---|
| Release track | Monthly releases, published on the 16th, fit teams that can re-test every month. ESR v11.7 fits teams wanting fewer upgrades; support ends 2027-05-15. | Monthly releases mean frequent offline transfers and plugin re-testing. An ESR means fewer cycles but a fixed end-of-support date to plan around. |
| Single node or cluster | A single node fits a smaller user base with a recovery window the team accepts. Clustering fits strict uptime needs and requires the Enterprise or Enterprise Advanced plan. | A single node has fewer moving parts. A cluster adds load balancers, replicas and failover testing, so confirm licensing before the design is final. |
| File store location | Local storage fits only a single node. A cluster needs S3, an S3-compatible service or NAS mounted on every node, because local storage risks file corruption. | Storage inside the enclave adds capacity, backup and access policy work. Confirm the chosen service and mount model with Mattermost before building. |
| Plugin sourcing and approval | A small, stable plugin set fits a lightweight approval step. A larger catalog needs a formal intake, security review and an approved-version list. | Each approved plugin is re-tested on every server upgrade. Plugins built internally must be packaged and transferred like any other artifact. |
| Patch transfer method | Removable media fits small, infrequent updates. Cross-domain transfer fits accredited channels. An internal mirror fits frequent updates across several systems. | Media needs logging and malware scanning at each transfer. A mirror needs sync jobs, integrity checks and an approval step. Confirm what your domain permits. |
| Internal package and container registry | A registry fits teams that deploy repeatedly or from several build hosts. Direct artifact transfer fits one-time installs with a single operator. | A registry adds hosting, access control, vulnerability scanning and sync duties. Without one, each upgrade needs a newly verified artifact set. |
Build sequence for an offline deployment
This sequence takes an enclave from contract confirmation to a verified, offline Mattermost server with every artifact traced in the change log.
Confirm plan tier and license entitlement
Your account lead confirms in writing that the subscription includes air-gapped deployment, which Mattermost lists under Enterprise Advanced on its pricing page. Ask how the license file is issued and renewed without internet access, and whether updates are delivered as offline packages. The step is done when the entitlement and delivery method are on file with the change record.
Freeze the target version and support window
Choose either a monthly server release, which Mattermost publishes in binary form on the 16th of each month, or an Extended Support Release. For the ESR track, v11.7 is supported until 2027-05-15. Record the version number, its end-of-support date and the planned next upgrade window. The step is complete when the pinned version appears in the change request.
Build the internal artifact repository
Mirror the server binary, PostgreSQL packages, operating system packages and any approved plugins into an internal repository on the enclave side. Staging is done on a connected host and transferred through your approved media process. Confirm the check passes by installing from the repository on a test host with outbound internet access blocked.
Record artifact checksums and versions
Calculate a checksum for every file in the repository and record it with its version, source, download date and the staging operator. Store the list in the change log and attach it to the release ticket. The step is verified when a second engineer recomputes the checksums inside the enclave and the values match the log exactly.
Install PostgreSQL and the server from staged artifacts
Install PostgreSQL first, then the Mattermost server, using only packages from the internal repository. Create the database and service account, then start the service. The step is confirmed when the service runs under its service manager, the server health check reports healthy, and the database accepts connections from the application host only.
Configure reverse proxy, TLS and email delivery
Place a reverse proxy in front of the server and issue its certificate from your internal certificate authority, with that authority's root installed on client devices. Point outbound email at an internal relay that the enclave can reach. The step is verified when a browser on an internal client loads the site over HTTPS without warnings and the relay accepts a test submission.
Load the license and run end-to-end checks
Upload the license file through the System Console and confirm the edition and seat count display correctly. Sign in from an internal client with a test account, then send a message and a file attachment between two test users. Confirm a test notification email arrives. The step closes when all checks pass and the results are added to the change log.
Effort and cost drivers
This table shows each driver that moves effort or cost in an air-gapped Mattermost rollout, who pays for it, why it matters, and how to keep it manageable, with the written scope setting the final effort.
| Driver | Who pays | Why it moves effort | How to keep it down |
|---|---|---|---|
| Enclaves and environments | Internal team and infrastructure owner, plus partner time for each environment | Each enclave needs its own install, configuration, offline update cycle and evidence set. Production, staging and test multiply the work. | Promote the same verified artifacts through each environment and rebuild none. Keep non-production enclaves small. |
| Users and concurrent load | Plan subscription for seats, and infrastructure for nodes, database replicas and file storage | Seat count sets the license tier. Peak concurrency sets node count, read replicas and shared file storage sizing. | Size from measured peak concurrency in a test enclave. Confirm with Mattermost which plan includes HA and air-gapped deployment before sizing. |
| Plugins and custom integrations | Internal team for vetting, partner for custom build and test work | Each plugin must be obtained, scanned, tested and carried through every release offline. Integrations are not transferred by migration tools. | Limit the plugin list, favor plugins you can build from source, and vet each version once per upgrade cycle. |
| Artifact set and transfer | Internal team and the transfer approvers, plus infrastructure for media handling | Server binaries, plugins, OS packages and dependencies cross the boundary each release. Server releases ship in binary form on a monthly cadence. | Bundle one release manifest with checksums, use one approved transfer path, and schedule transfers on a fixed cadence. |
| Accreditation and assessment evidence | Internal compliance team, partner for control and evidence preparation, and third-party assessors | Assessors expect configuration baselines, access records, patch logs and transfer records. Missing evidence repeats work. | Agree the evidence list before the build starts. DeployOpen prepares evidence but does not issue audit reports or certifications. |
| Linux, PostgreSQL and certificate skills | Internal staff, or partner time where in-house skills are missing | Offline hosts need manual OS patching, PostgreSQL backup and restore, and internal CA certificate handling without vendor help. | Confirm skill coverage early. Cross-train at least two people per skill and document the offline runbook. |
Differences by deployment model
A single-node install runs the Mattermost server on one Linux host with PostgreSQL, which makes it the simplest model to move into an enclave. Every component is transferred as a set of files, so the offline work centers on inventory, checksums and a repeatable transfer process.
- Extra artifacts: the server package, PostgreSQL and reverse proxy packages, operating system dependencies and any plugin bundles, each mirrored and verified before transfer.
- Upgrade effect: the single host is updated in one maintenance window, so the service is unavailable while the binary is replaced and database migrations run.
- Testing burden: a staging copy inside the enclave is still needed to rehearse each upgrade, but only one configuration has to be validated.
- Limit to plan for: there is no redundancy, so a host or storage failure stops messaging until the system is restored from backup.
A clustered deployment requires a license that includes high availability, which Mattermost lists on Enterprise and Enterprise Advanced. Air-gapped deployment is listed on Enterprise Advanced, so confirm the entitlement before design starts. Each application node runs the same version against shared file storage, with database read and search replicas attached.
- Extra artifacts: identical server packages for every node, load balancer configuration, replica database settings, and an S3-compatible or NAS file store mounted on each node.
- Upgrade effect: nodes are updated one at a time in a controlled sequence so the remaining nodes keep serving users.
- Testing burden: application node failover, database primary and replica behavior, and file access from every node must be exercised before go-live.
- Confirm with Mattermost: the offline steps for clustered installs, including how storage and replicas are staged in an air-gapped network and whether mixed versions are supported during the sequence, for your specific version.
A Kubernetes enclave deployment runs Mattermost in a cluster that the organization operates inside the air gap. The cluster's own image registry, chart handling and signing controls become part of the Mattermost supply chain, so they need the same scrutiny as the application.
- Extra artifacts: mirrored container images, chart or manifest bundles, values files, and the internal registry and certificate trust the cluster needs.
- Upgrade effect: pods are replaced by the workload controller in a controlled sequence, tied to the image and chart versions you mirror into the enclave.
- Testing burden: verify image provenance, storage class behavior for file storage, network policy rules and the cluster's own upgrade cycle alongside Mattermost's.
- Confirm with Mattermost: the offline Kubernetes steps, pod ordering and which plan covers this model in your enclave, since the air-gapped entitlement is listed on Enterprise Advanced.
Verifying the enclave install and upgrade path
Verification for an air-gapped Mattermost install has one goal: show that the server runs from staged artifacts, reaches only internal services, and can be restored and upgraded without any internet access. Start with the egress test. Run the server with outbound traffic blocked at the firewall and DNS sinkholed, then exercise startup, login and a sample of features. Capture logs and firewall counters as evidence. Any attempted connection to an external host is a finding, and it should be traced to a plugin, a telemetry setting or a build-time dependency before the install is accepted.
Next, confirm licensing and plan features match the written scope. Check that the uploaded license shows the expected edition and seat count in the System Console, and that features the enclave depends on, such as air-gapped deployment support and any SSO or cluster features you purchased, report as enabled. Confirm the license expiry date and who owns renewal. Then run functional checks that a user would notice: sign in through the chosen identity path, create a public and a private channel, upload files of the sizes your policy allows, and search for content inside those files. Record which test accounts and data sets you used so the checks can be repeated after each change.
Notifications need their own test. Send email notifications through the internal mail relay to mailboxes you control and confirm delivery, headers and the sender address your relay expects. For mobile push, do not assume delivery. Confirm with the vendor and your own environment exactly how push notifications behave when the enclave cannot reach the external push service, and record the limits in your runbook so users know what to expect. Treat any gap as a documented risk with an owner, not as a passed test.
The upgrade and recovery rehearsals decide whether the enclave is supportable. Stage the next version's server binary and any plugin packages, then upgrade a copy of the environment using only those transferred artifacts and the existing PostgreSQL and file storage backups. Run the same functional checks before and after. Then test a rollback to the previous binary, and a full restore from PostgreSQL and file storage backups into a clean host. Time each step, record which artifacts were missing, and confirm the restored data matches the pre-test baseline before you sign off.
Operating the enclave after go-live
This table lists each recurring task for the air-gapped Mattermost enclave with its owner, cadence and the evidence to keep for assessors.
| Task | Owner | Cadence | Evidence to keep |
|---|---|---|---|
| Release review against support dates | Platform engineering lead | Monthly, after each 16th release, and against ESR dates | Dated review record showing the running version and its support end date, such as v11.11 ending 2026-12-15 |
| Artifact transfer and verification | Platform team with the security authority | Each release, before any install or upgrade | Transfer log, checksum or signature check results and the approved path. Confirm this process with your security authority first |
| Plugin re-approval | Plugin owner with a security reviewer | After each server upgrade, before plugins are re-enabled | Test results against the new server build, approval record and the plugin version in use |
| License and plan renewal tracking | Procurement with the IT service owner | Tracked continuously, reviewed before each renewal date | Current plan, seat count and renewal date. Air-gapped deployment is listed on the Enterprise Advanced plan |
| PostgreSQL and file store backups with tested restores | Database administrator and storage administrator | Backups on the schedule in the runbook, restore tests at an interval set by your recovery targets | Backup job logs, restore test reports and time to recover from each test |
| Service health and disk monitoring | Operations on-call team | Continuous alerting, with a daily review of trends | Alert history, capacity trend reports and records of disk and database connection thresholds |
| Certificate renewal with internal CAs | PKI team with the platform engineer | Scheduled ahead of each certificate expiry date | Certificate inventory with expiry dates, renewal tickets and client trust chain tests after each change |
| Build, artifact inventory and change history | Platform engineering with the compliance lead | Every release and every configuration or plugin change | Build record, artifact hash inventory and a change log that assessors can trace back to each release |
Questions buyers and engineers ask
Does an air-gapped Mattermost deployment require the Enterprise Advanced plan?
Mattermost's pricing page lists air-gapped deployment under Enterprise Advanced, so plan your quote against that plan. Mattermost sells Professional, Enterprise and Enterprise Advanced as prepaid annual subscriptions priced by seat licenses, and the pricing page lists no public prices, so buyers contact sales for figures. Confirm in writing which plan covers your deployment model, support terms and seat count before you finalize scope. DeployOpen implements the deployment inside your enclave, but licensing terms come from Mattermost.
What does an air-gapped Mattermost deployment cost and what drives it?
DeployOpen does not publish prices, and a quote follows from a written, fixed scope. Cost has two sources: the Mattermost subscription, which recurs annually by seat, and the implementation work, which is largely one-time. The main scope drivers are the number of environments (for example production, staging and a test enclave), how many artifacts must cross the boundary for each release, the number of plugins and whether each one must be reviewed and transferred, and how much evidence your assessors expect. Ask for a quote that separates one-time work from recurring support.
How long does an air-gapped Mattermost deployment take?
The duration is set by the written scope, not by a standard figure. Timing depends on how many environments are built, whether the enclave's operating system, PostgreSQL, certificates and mail relay are ready when work starts, how long your transfer approval process takes, and how many plugins need offline review. Mattermost releases server versions in binary form on the 16th of each month, so a slow transfer process can leave you behind the current release. Ask for milestones tied to each dependency you control.
What skills and resources must our internal team supply?
Your team supplies the platform the server runs on and the approvals that let software enter the enclave. Mattermost runs as a single Linux binary with PostgreSQL as its database, so you need Linux administration and PostgreSQL administration skills. You also need storage for files and backups, TLS certificates from your internal certificate authority, an internal mail relay for notifications, and a documented transfer process approved by security. Confirm a named owner for each item before the scope is signed.
Can a capable internal team deploy Mattermost air-gapped without a partner?
Yes, a capable internal team can do it alone if a runbook and an approved transfer process exist. Mattermost's single binary, PostgreSQL dependency and published deployment planning give experienced Linux and database engineers a clear starting point. The harder parts are repeatable: building an offline artifact bundle, verifying it, and moving each monthly release or Extended Support Release update through approval. A partner can write the runbook, implement the first deployment and hand over the transfer process if your team prefers that route.
What should we confirm about push notifications and plugin sources before committing?
Confirm with Mattermost how mobile push notifications reach devices when the server has no internet access, and whether any relay service must be reachable from the enclave. Also confirm where each plugin's code comes from, whether it can be downloaded, verified and transferred offline, and whether it is supported on your server version. Get these answers in writing before the scope is signed, because they can change the architecture and the approvals you need. Both can be tested during the pilot if they are included in the scope.
How DeployOpen scopes, builds and hands over this work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For Mattermost, that means a written scope that covers offline installation, the offline update path into the enclave, and the licensing and plan requirements that apply to an air-gapped environment.
How we scope
- Confirm the air-gapped boundary, the enclave hosts and the approved path for moving files in and out.
- Confirm which Mattermost plan and license terms apply, since air-gapped deployment is listed under Enterprise Advanced.
- Agree the release channel, monthly or Extended Support Release, and how each upgrade will be staged and approved.
- Record which plugins, identity providers and integrations are in scope and which are excluded from the offline build.
How we build
- Prepare an offline artifact set for the server binary, PostgreSQL, file storage and any approved plugins.
- Build and test the installation in a staging enclave that mirrors network restrictions and push notification limits.
- Document the update transfer procedure, including checksums, review steps and rollback points for each release.
- Test the high availability design, if in scope, including shared file storage and database failover in the enclave.
How we hand over
- Deliver runbooks for installation, upgrades, backups, restores and plugin changes, written for your operations team.
- Walk your administrators through the offline update procedure and run a supervised upgrade rehearsal with them.
- Provide configuration records, access lists and a list of open items agreed in the written scope.
- Confirm the handover acceptance criteria in writing before the engagement closes.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped to your release channel and enclave.
- Support can cover monitoring of the offline update queue and review of each Mattermost release notes before it is staged.
- Confirm with your team which support hours, response terms and escalation paths apply, as these are set in the retainer.
- Agree how plugin and integration testing will be repeated before each upgrade in the enclave.
