Why Slack cannot serve a disconnected network and which self-hosted chat can
A network with no internet route needs team chat that runs entirely inside it, so the first test for any product is whether it can be installed and operated without a connection to its vendor's cloud. Slack cannot pass that test. It is delivered as a cloud service, and it has no deployment that runs inside your own network. The documented self-hosted options for disconnected networks are Mattermost's air-gapped deployment path, Rocket.Chat's Government and Defense plans, and the Sovereign edition of Element Server Suite, which runs Matrix on your own servers.
In each case, air-gapped deployment is a paid capability, not something the free editions provide. Mattermost places air-gapped deployment in its Enterprise Advanced plan, and Rocket.Chat states that air-gapped deployment is not available on its free Starter plan. Element's Sovereign edition is one of the paid tiers above the free AGPL Community edition. Pricing for all three is quoted by sales rather than published, so ask each vendor in writing which features the air-gapped tier includes, how license validation works without internet access, how offline updates are delivered, and what support covers. Vendor pricing pages are the place to start: Mattermost pricing, Rocket.Chat pricing and Element pricing.
The choice depends on three things. Platform: Mattermost runs as a single Linux binary with PostgreSQL, Rocket.Chat 8.x needs a MongoDB 8.0 or later replica set, and Synapse needs PostgreSQL 14 or newer for recent releases. Licensing: Mattermost offers AGPL v3.0 source under a commercial alternative, Rocket.Chat keeps its ee directories under an enterprise license, and Element sells AGPL exceptions for Synapse. Operations: Mattermost releases server versions monthly, Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months, and Synapse warns that rolling back can be difficult because of schema changes. Your team will have to run offline upgrades on a fixed schedule, so test that process in a staging enclave before you commit.
What an air-gapped chat deployment must satisfy
A disconnected chat server has to run without help from a vendor cloud, take updates by hand, keep files inside the enclave, and sign users in through the network's own directory. Each card below is a constraint that shapes the choice between Mattermost, Rocket.Chat and Matrix with Element, and each one has a question to put to the vendor before procurement.
No dependence on vendor cloud
Some features depend on services hosted by the vendor. Rocket.Chat states that after end of life a version gets no security or bug fixes and that cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. On a disconnected network, confirm which features still work with no outbound route, including mobile push, and which need a relay you host yourself.
Offline upgrades and license handling
Every release has to be carried into the enclave on media you control, and rollback is not always simple. The Synapse upgrade notes warn that rolling back can be difficult because of database schema changes. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, so plan a repeatable upgrade path. Confirm with each vendor how licenses are issued and renewed for a network with no internet access.
Files kept inside the enclave
Attachments and uploads must stay on storage inside the enclave. 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. Choose an on-premises S3-compatible store or NAS before you size the servers, and confirm backup of that store separately from the database.
Identity through the network's directory
Users should sign in with the directory the enclave already trusts, not with local accounts that drift over time. Rocket.Chat's Starter plan includes LDAP and Active Directory authentication, but air-gapped deployment is a paid-plan capability. Mattermost places SSO and AD/LDAP sync from the Professional plan and air-gapped deployment in Enterprise Advanced. Synapse supports OpenID Connect, SAML2 and CAS. Confirm group mapping and deprovisioning against your own directory.
Database topology the product needs
Each product brings its own database layer, and that layer sets the hardware and operator skills you need. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, with three members recommended for high availability. Synapse recommends PostgreSQL for production and requires PostgreSQL 14 or newer for version 1.143.0 and later. Mattermost is built on PostgreSQL. Ask who in your team will operate the chosen database inside the enclave.
High availability and redundancy scope
Redundancy has a cost that shows up in licensing and in infrastructure. Mattermost high availability, with redundant application servers, database servers and load balancers, is available only on Enterprise and Enterprise Advanced. Rocket.Chat's multi-instance and microservice designs require a paid plan. Decide whether a single instance with a replicated database is enough for your user count, and confirm the disaster recovery path the enclave's own policy requires.
How Mattermost, Rocket.Chat and Element meet the disconnected-network constraint
This table compares the three air-gapped options and flags two free tiers that do not cover disconnected use. Read each row for the air-gapped path, license terms, database and storage needs and operating trade-offs. The main takeaway is that every option that works offline sits on a paid tier, so confirm the offline update path and license terms in writing before you choose.
| Option | Air-gapped support | Licensing and database needs | Trade-offs |
|---|---|---|---|
| Mattermost Enterprise Advanced | Air-gapped deployment is listed for Enterprise Advanced on Mattermost's pricing page. Confirm the offline update process in writing. | Compiled binaries under MIT, source under AGPL v3.0 or a commercial license. Runs on PostgreSQL. | High availability needs shared S3-compatible or NAS storage on every node, since local storage risks file corruption. HA requires Enterprise or higher. |
| Rocket.Chat Government and Defense | Air-gapped and sovereign deployment is a paid-plan capability. Confirm offline upgrade and licensing terms for your network. | MIT outside the enterprise directories, with ee directories under Rocket.Chat's enterprise license. Requires MongoDB 8.0 or later as a replica set. | Standard releases get 6 months of support and LTS releases 12, so offline upgrades must be scheduled. Cloud-dependent services stop after end of life. |
| Element Server Suite Sovereign edition | The Sovereign edition is listed for air-gapped deployments on Element's pricing page. Confirm component scope and update channels. | Synapse is AGPL-3.0 with commercial licenses from Element. Production runs on PostgreSQL, version 14 or newer for Synapse 1.143.0 and later. | Rolling back can be difficult because of schema changes between releases. Larger deployments need Redis for workers. Federation can be switched off. |
| Mattermost Team Edition (not covered) | Not covered. Air-gapped deployment is listed for Enterprise Advanced, not the free edition. | Free and self-hosted, with compiled binaries under MIT. Aimed at teams under 250 users that do not need SSO. | No SSO, AD/LDAP sync or high availability. Treat it as out of scope for disconnected networks. |
| Rocket.Chat Starter (not covered) | Not covered. Air-gapped deployment is not available on Starter, which is free for up to 50 users. | Free self-managed workspace. Code outside the enterprise directories is MIT-licensed. | Includes LDAP, SSO, MFA and end-to-end encryption, but it cannot serve as the disconnected deployment. A paid plan is required first. |
Which option fits which network situation
If your network must integrate single sign-on and run several application nodes for resilience, the decision turns on paid editions. Mattermost includes SSO (SAML, OIDC, OAuth) and AD/LDAP sync from the Professional plan, while high availability clustering and FIPS 140-3 compliance start at Enterprise, and air-gapped deployment is listed for Enterprise Advanced. Mattermost high availability needs redundant application servers, database servers and load balancers, plus shared file storage such as S3-compatible storage or NAS on each node. Rocket.Chat's Government and Defense plans list LDAP and SAML group mapping, SSO and built-in failover, but its multi-instance designs need a paid plan once you pass 500 concurrent users.
- Edition boundary: Mattermost clustering is limited to Enterprise and Enterprise Advanced, so budget for those tiers before you design the cluster.
- Shared storage: Local file system storage will not work correctly in a Mattermost cluster and risks corrupting files.
- Rocket.Chat scaling: Load-balanced instances linked by NATS are a paid-plan design above 500 users.
- Operations: Both platforms need a database tier that stays online during failover, which your own team or DeployOpen must maintain.
- Matrix as a comparison: Synapse supports OIDC, SAML2 and CAS directly in its configuration.
Confirm with each vendor which features are included in the exact edition quoted for air-gapped delivery, and whether the high availability design is supported on disconnected infrastructure.
A smaller enclave with a limited user count and a fixed set of hosts usually cares more about operational simplicity than clustering. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Node.js is bundled in the official Docker image and Helm chart, which reduces the number of runtimes you maintain on the host. A single instance with a MongoDB replica set is the reference point for deployments up to 500 concurrent users. Mattermost runs as a single Linux binary with PostgreSQL, which gives a smaller set of moving parts but no high availability outside its paid tiers.
- Three-member replica set: Plan three MongoDB nodes, each on separate hardware or failure domains, if you want the recommended high availability layout.
- Single binary: Mattermost's single Linux binary and PostgreSQL database make it the smaller footprint to patch and back up.
- Offline upgrades: Rocket.Chat support windows of six months for standard releases and twelve months for LTS mean you must move versions regularly, even when disconnected.
- Cloud dependencies: Push notification gateway, Marketplace and Omnichannel integrations stop after end of life, so confirm which of them your enclave depends on.
- Free tiers: Rocket.Chat Starter and Mattermost Team Edition have user limits, so check them against the enclave headcount.
Confirm with each vendor the supported MongoDB or PostgreSQL versions for your enclave, the offline update path, and whether the free tiers permit air-gapped use.
If the requirement is to control who your network can talk to, Matrix gives the most direct control over federation. Synapse federates on port 8448 by default, and the federation_domain_whitelist setting limits federation to listed domains. An empty list disables federation entirely, and the Synapse docs recommend also firewalling the federation listener. Synapse is developed by Element and licensed under AGPL-3.0, with commercial licenses from Element. Element Server Suite includes a Sovereign edition for air-gapped deployments, which is the commercial path that matches disconnected operation. Synapse production deployments are documented on PostgreSQL, and its workers scale through Redis.
- Federation allow-list: Set federation_domain_whitelist to the listed partner domains, or leave it empty for a closed network.
- Listener firewalling: Block the federation listener at the network edge even when the allow-list is set.
- Server name: The server_name setting fixes how user IDs such as @user:example.com and rooms are identified, so it cannot change casually after launch.
- Licensing: Compare the AGPL Community edition with Element Server Suite Pro and Sovereign terms before you commit.
- Upgrade risk: Synapse notes that rolling back can be difficult because of schema changes between releases.
Confirm with Element which Sovereign edition components are supplied for disconnected networks, what the AGPL obligations mean for your use, and which Synapse release your PostgreSQL version supports.
How to deploy chat inside a disconnected enclave
This sequence takes a disconnected network from a licensing check to a running, patchable chat service whose packages, database and identity sources all sit inside the enclave.
Confirm the plan and license for air-gapped use
Before any hardware is staged, the platform owner confirms in writing that the chosen edition permits air-gapped deployment. Mattermost lists air-gapped deployment under Enterprise Advanced, and Rocket.Chat states that air-gapped deployment is a paid-plan capability and is not available on Starter. Element's Sovereign edition is the Element option for disconnected networks. Ask each vendor to confirm the offline license mechanism, how license keys are renewed without internet access, and which features stop working if a key lapses. Done when the signed license terms and the edition are recorded in the change request.
Size the database tier
The database team sizes the primary database that the chosen platform needs. Mattermost and Synapse use PostgreSQL, and Synapse 1.143.0 and later require PostgreSQL 14 or newer. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Confirm storage growth with your own message volume estimates, since vendors do not supply a universal sizing figure here. Done when the database versions, replica topology and backup targets are documented and approved.
Provision shared file storage for clustered Mattermost
If Mattermost will run as a high availability cluster, the infrastructure team provisions shared storage that every application node can mount. Mattermost's documentation says the cluster requires Amazon S3, an S3-compatible service or NAS mounted on each node, and that local file system storage will not work correctly and risks corrupting files. In an enclave, this usually means an on-premises S3-compatible object store or NAS. Test that every node reads and writes the same files before the application tier is installed. Done when a file uploaded through one node is retrievable from all others.
Configure identity against the internal directory
The identity team connects the chat platform to the enclave's directory service. Mattermost includes AD/LDAP user sync and SSO (SAML, OIDC, OAuth) from the Professional plan. Rocket.Chat's Starter plan includes LDAP and Active Directory authentication, and its paid plans add SAML user group mapping. Synapse supports OpenID Connect, SAML2 and CAS. Confirm group mappings, deprovisioning behavior and how MFA is enforced with the identity provider inside the enclave. Done when a test account from each directory group can sign in and a disabled account is locked out.
Stage offline packages and images through the transfer process
The platform owner builds an inventory of every artifact the deployment needs: server binaries or container images, the Helm chart or Docker images where used, operating system packages, database packages, and the mobile and desktop client builds. Each item moves through the enclave's approved cross-domain or media transfer process, and its checksum is verified on the inside. Mattermost publishes server binaries on the 16th of each month, and Rocket.Chat and Synapse publish on GitHub, so the staging list should name the exact version and checksum. Done when the internal artifact repository holds every item and the checksums match the vendor's published values.
Import users and channels from existing exports where needed
If the enclave is replacing an earlier chat system or a Slack workspace exported before the move, the migration team runs the import in a test instance first. Mattermost migrates Slack exports with mmetl and mmctl, and integrations, custom emoji images, user groups and Slack Connect channels do not move. Rocket.Chat imports full Slack exports through Manage, Workspace, Import, and recommends splitting large exports into files under 15 MB. Synapse has no equivalent importer, so Matrix history usually stays in the source system. Done when a sample channel's messages, threads and attachments are checked against the source.
Plan upgrades against the support windows
The operations team writes an upgrade calendar before go-live. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and after end of life a version gets no security or bug fixes and cloud services stop working. Rocket.Chat also says unsupported versions may lose connection to official mobile and desktop clients. Mattermost publishes ESR and standard releases with stated end-of-support dates, and Synapse warns that rollback can be hard because of schema changes. Rehearse each upgrade in an offline staging copy and keep database backups before each change. Done when the calendar, rollback plan and staging rehearsal record are signed off by the service owner.
What moves from Slack into an air-gapped server
The export path into an air-gapped server depends on the platform, so plan the migration around each product's importer before you choose one. Mattermost converts a Slack export with mmetl into its bulk import format, then loads that file with mmctl. Users, channels, direct messages, threads and attachments move through this path. Rocket.Chat takes a full Slack workspace export through Manage, Workspace, Import, and its documentation recommends splitting large exports into files under 15 MB. Because a disconnected network cannot pull anything from the internet during cutover, stage the conversion and import on a connected staging system first, then carry the verified files across on approved media.
Several things do not come across in either path. Integrations, custom emoji images, user groups and Slack Connect channels stay behind, so the inventory of bots, webhooks and shared-channel dependencies must happen before the Slack export is requested. The export itself is limited by the Slack plan that produced it. Public channels export on every plan, but private channels and direct messages require an approved Business+ or Enterprise application, and custom exports by member or conversation are Enterprise-only. Confirm with the workspace owner which plan is active and what was approved, because an export that lacks private conversations cannot be repaired later inside the air-gapped server.
Ask the platform team to record exactly what was exported and what was imported, including channel counts, user counts and a sample of threads and attachments checked by hand. Compare these against the source before users sign in. Decide early whether users will be mapped to accounts created from your identity provider or to new local accounts, since that choice affects who can log in once the disconnected network goes live. Confirm each vendor's current import limits and supported Slack export fields with the vendor before the staging run, because these details change between releases.
Evidence assessors and security teams ask for
Assessors and accreditation teams will ask what is running, under which license, and how it stays current without internet access. The cards below list the artifacts that answer those questions for any of the three platforms. DeployOpen prepares these artifacts, but auditors and accreditation bodies make the decisions.
Deployed version and upgrade record
Record the exact server build, the release date and the support end date for the version in production, and keep a dated log of every upgrade and patch. Mattermost publishes a new server version each month, with Extended Support Releases on a longer cycle, so an assessor will want to see that the running line is still within support. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, so the upgrade log should show a planned path to the next supported line. Confirm the support window for your chosen line with the vendor before you sign off.
License and plan covering air-gapped use
Air-gapped deployment is a paid capability on the main platforms, so the plan on the purchase order has to match the deployment model. Mattermost lists air-gapped deployment in Enterprise Advanced, and Rocket.Chat restricts it to paid plans and not Starter. Element offers a Sovereign edition for air-gapped deployments. Keep the signed order, the license file and the license terms together with the architecture record, and confirm with each vendor in writing that the license covers the offline installation and the number of users.
Database and file storage configuration
Assessors check where message data physically lives and whether it is backed up consistently. Mattermost high availability requires shared file storage on NAS or an S3-compatible service, because local file system storage will not work correctly and risks corrupting files. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set. Synapse recommends PostgreSQL for production. Document the database versions, replication topology, storage locations and the backup and restore test results for each.
Identity and access settings
Show how users are authenticated and how access is removed. Rocket.Chat's Starter plan includes LDAP and Active Directory authentication, single sign-on and multi-factor authentication, while Mattermost gates SSO and AD/LDAP sync behind the Professional plan. Synapse supports OpenID Connect, SAML2 and CAS. Export the identity provider configuration, the role mappings, the MFA policy and the joiner and leaver procedure, and confirm that disabled accounts lose access to the server in practice.
Retention and audit configuration
Retention and audit records decide what an investigator can later reconstruct. Mattermost compliance export and Rocket.Chat's tamper-evident audit trails are paid features, and Element's Synapse federation can be restricted to listed domains or switched off entirely. Record the retention periods set for each channel type, the audit log export process, and the federation policy. Ask each vendor which of these controls is present in your edition before the design review.
Offline update procedure
Without internet access, every patch has to be brought in through a controlled transfer, and the transfer is itself a risk. Rocket.Chat notes that unsupported versions lose the ability to connect to official mobile and desktop clients, and some cloud services such as the push notification gateway stop working after end of life. Document how release packages are obtained, verified and moved across the boundary, how they are tested in a staging environment, and who approves each change. DeployOpen can prepare this runbook, and the accreditation body decides whether it is sufficient.
Questions buyers ask before deploying Slack alternatives offline
What drives the cost of an air-gapped chat deployment?
The cost comes from four parts: the license plan, hosting, admin time and migration. Air-gapped deployment is a paid capability on both Mattermost and Rocket.Chat. Mattermost lists air-gapped deployment in its Enterprise Advanced plan, and Rocket.Chat restricts air-gapped deployment to its paid Commercial, Government and Defense plans, not Starter. Mattermost sells its plans as prepaid annual subscriptions priced per seat, and neither vendor publishes prices, so the license line must come from a vendor quote. Hosting, staff time for patching and backups, and the one-time migration recur or are one-time in different ways. Ask each vendor for a written quote that separates license, support, hosting assumptions and any migration work.
Can our own team run an air-gapped Slack alternative without outside help?
A team with Linux, PostgreSQL or MongoDB, and container or Kubernetes skills can run it, but the work is continuous rather than one-time. Mattermost runs as a single Linux binary with PostgreSQL, while Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, with three members recommended for high availability. Each platform needs upgrades every month or two, and Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. Unsupported versions lose security fixes and may stop connecting to official mobile and desktop clients. Decide who owns patching, backups and offline update packages before you choose a platform.
How long does an air-gapped rollout take, and what drives that time?
No supplied figure gives a duration, so treat any timeline as something to agree in writing, not a benchmark. The main drivers are the number of users and channels, whether single sign-on and directory sync are required, the size of the Slack history to migrate, the number of integrations to rebuild, and whether a high availability cluster is needed. Mattermost high availability requires shared file storage on Amazon S3, an S3-compatible service or NAS on every node, and Rocket.Chat's multi-instance designs require a paid plan. Ask the implementation partner for a fixed scope with deliverables and milestones before work starts.
What does the work need from our staff?
Your staff must supply the network, infrastructure and identity decisions, plus people who can operate the platform after handover. Typical inputs include a host or Kubernetes environment inside the enclosure, a database layer, shared file storage for Mattermost clusters, a way to get signed offline packages across the boundary, and an identity provider for single sign-on. Mattermost SSO (SAML, OIDC, OAuth) and AD/LDAP sync start at the Professional plan. Name owners for each item, and ask the vendor or partner which of these your environment already provides.
Can we move our Slack history into an air-gapped chat server?
Yes for most content, but the export plan decides what you can take out. Every Slack plan can export public channel messages, while private channels and direct messages require a Business+ or Enterprise plan, and custom exports by member or conversation are Enterprise-only. Mattermost's migration path converts a Slack export with mmetl and loads it with mmctl, moving users, channels, direct messages, threads and attachments. Integrations, custom emoji images, user groups and Slack Connect channels do not move. Rocket.Chat imports full Slack exports and recommends splitting large exports into files under 15 MB. Confirm your export plan before you start, and ask the partner to test a sample import.
How do upgrades work when the network has no internet access?
Upgrades offline depend on moving signed release packages across your approved transfer process, then testing them in a staging copy first. Mattermost publishes a new server version in binary form on the 16th of each month, and Mattermost v11.7 is an Extended Support Release supported until 2027-05-15, which lowers how often you must upgrade. Synapse warns that rolling back can be hard because of schema changes, so take database backups before each upgrade. Rocket.Chat says unsupported versions may also lose connections to official clients. Ask each vendor how it delivers offline packages and which support window applies to your contract.
How DeployOpen works on this
DeployOpen plans, builds, hardens and documents self-hosted chat inside your own networks, including disconnected ones where no cloud service is reachable. We start from your classification, identity and retention rules, then choose between Mattermost, Rocket.Chat and Matrix with Element against the constraints you actually face.
How we scope
- We confirm which network zone, offline update path and identity source the chat server must use before any build work starts.
- Scope is agreed in writing with deliverables and timelines fixed before work begins, so the boundary of the engagement is clear.
- We check which required features sit behind paid editions, such as air-gapped deployment, SSO and high availability, and record them in the scope.
How we build
- We install the chosen platform and its database, file storage and search components inside your offline environment, without relying on external services.
- We configure identity integration, retention settings and channel access to match your written policies rather than vendor defaults.
- We test backup and restore, failover where the edition supports it, and the offline upgrade procedure before handing anything over.
How we hand over
- You receive documentation covering architecture, configuration, runbooks for upgrades and recovery, and the list of cloud features that do not work offline.
- We prepare the controls and evidence your internal teams or independent auditors need, without issuing any audit report or certification ourselves.
- Knowledge transfer sessions cover day-to-day administration so your own staff can operate the platform after handover.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the fixed-scope engagement ends.
- We plan upgrades around each platform's published release and support windows, which you confirm with the vendor for your version.
- Security testing of the deployed chat service, including applications, infrastructure and integrations, can be scoped separately under a written agreement.
