Which Slack alternative for air-gapped networks fits a disconnected environment
If your team must keep chat inside a network with no internet path, Slack's cloud model cannot be used at all. The main self-hosted candidates are Rocket.Chat's paid Government and Defense or Commercial plans and Mattermost Enterprise Advanced, with Element's Sovereign edition for Matrix as a third option. Air-gapped deployment is a paid capability on all three, so the licensing decision comes before the architecture decision. Rocket.Chat excludes air-gapped deployment from its free Starter plan, and Mattermost lists it in Enterprise Advanced, so budget for the paid tier from the start and get the terms in writing.
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. In a disconnected network, that means the MongoDB packages, the Rocket.Chat container images or Helm chart, and any Node.js dependencies must be mirrored into your internal registry and verified before cutover. Ask the vendor which MongoDB and replica set configuration they support for your reference architecture size, since the reference designs differ once you move beyond 500 concurrent users. Plan the replica set's own upgrade path as well, because it is a separate component from the chat application.
Offline upgrades are the hardest recurring task. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and after end of life cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Confirm which features your deployment depends on that need internet access, such as push notifications to mobile clients, and whether the vendor's Government and Defense plan provides an offline update channel. Build a dated runbook that moves each release through an approved transfer process, and check every artifact against its published hash before it crosses the boundary.
What an air-gapped network requires from chat software
A disconnected network removes the cloud services that most chat products quietly depend on, so the platform has to run, update and be administered entirely inside the boundary. The four requirements below connect the software choice to the database, the update path and the people who can reach the system.
No runtime dependence on internet services
Before any deployment, list every outbound call the chat server makes: push notification gateways, marketplace lookups, license checks, telemetry and link previews. Rocket.Chat's cloud-backed services, including the push notification gateway, Marketplace and Omnichannel integrations, stop working once a version reaches end of life, so you must also confirm which of them work on an isolated network. Ask the vendor to document each service that needs outbound access and which ones it can run without.
A database layer inside the boundary
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. Every member, its storage and its backups must sit inside the isolated network, with the replica set's internal certificates and key material managed locally. Confirm that your approved MongoDB build and its packages can be mirrored into the enclave before you commit to the architecture.
Verified transfer of software across the boundary
Containers, Helm charts, operating system packages and vulnerability feeds all cross the boundary on removable or diode-controlled media. Each artifact needs a recorded hash, a signature check against the vendor's published key and a controlled import into a local registry. NERC CIP-013-2 is one energy-sector example: its supply chain controls require procurement processes that address verifying software integrity and authenticity for vendor software and patches. Other regulators may impose different controls, so confirm your own requirements.
Controlled remote access for vendors
Vendor engineers who support an isolated chat server need remote sessions that do not reach into the enclave unchecked. NERC CIP-005-7 is an energy-sector example that requires interactive remote access to pass through an Intermediate System with encryption and multi-factor authentication, and that active vendor sessions can be detected and disabled. Decide whether your vendor support will be on-site only, brokered through a jump host or unavailable, and document the session logging for each option.
Upgrade path that outlasts support
Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and an unsupported version can lose the ability to connect with the official mobile and desktop clients. On a disconnected network, each upgrade needs a rehearsed offline transfer, so plan the cadence against the length of your change approval process. Ask the vendor which release line is currently LTS and how long it stays supported.
Where Slack's cloud model stops working for disconnected networks
Slack cannot be moved into a disconnected network because the service itself runs in Slack's cloud. Messages, files, search and the apps that sit on top of them are hosted and operated by Slack, so no admin setting turns a Slack workspace into something you can run inside an enclave. For a network with no route to the internet, the question is not whether Slack's controls are sufficient but whether the deployment model can exist there at all. It cannot, which is why the replacement has to be a server you install and operate yourself.
The cloud model also decides how much of your history you can take with you. Slack's Free plan keeps 90 days of message and file history, and Slack states that content on Free workspaces older than one year is permanently deleted. Every plan can export messages and file links from public channels, but exporting private channels and direct messages requires Business+ or Enterprise, and custom exports by member or conversation are Enterprise-only. Before any cutover, confirm which plan the workspace is on, whether an export request for private channels and DMs has been approved, and who in legal or records management owns the decision about what must be preserved. Slack's export documentation sets out what each plan can extract.
Plan the extraction as its own workstream. Inventory the channels and conversations that carry records you must keep, check their age against the Free plan deletion window, and export them while the plan still allows it. Data that has been deleted under the one-year rule cannot be recovered by a later migration, so the export scope should be signed off before the disconnected network is built. Whatever you export then becomes the material that Rocket.Chat's importer will read, so its completeness sets the ceiling for what the new workspace can contain.
Rocket.Chat, Mattermost and Element compared for disconnected networks
This table compares the three self-hosted chat platforms on air-gapped availability, free tier limits, licensing and the Slack migration path. Read the plan row first, because air-gapped use is a paid-plan capability on each platform. Items marked as questions are not confirmed by the published facts and should go to the vendor in writing.
| Criterion | Rocket.Chat | Mattermost | Element Server Suite |
|---|---|---|---|
| Air-gapped plan requirement | Paid only: Commercial, Government or Defense plans; not available on Starter | Listed under Enterprise Advanced | Sovereign edition, which is built for air-gapped deployments |
| Plan to confirm for classified use | Ask whether Government or Defense is required for your accreditation scope | Ask whether Enterprise Advanced covers your classification level | Ask whether Sovereign covers your classification level |
| Free tier limits | Starter allows up to 50 users with LDAP, SSO, MFA and end-to-end encryption; Community allows up to 100 concurrent users | Team Edition is free for teams under 250 users without SSO; Entry caps history at 10,000 messages | Community edition is free under AGPL and includes Synapse and Element Call; it is not an air-gapped edition |
| Licensing | MIT outside the enterprise directories; enterprise license under the ee directories | AGPL v3.0 or a commercial license from Mattermost, Inc.; admin tools under Apache 2.0 | Synapse and Dendrite under AGPLv3 since November 2023; commercial licenses from Element |
| Database and hosting | MongoDB 8.0 or later as a replica set, three members recommended for high availability | Confirm the database and clustering requirements for disconnected operation with Mattermost | Confirm the Synapse database and worker setup for the Sovereign edition with Element |
| Upgrade cadence | Standard releases supported 6 months, LTS 12 months; unsupported versions lose cloud services | Confirm the offline patch and release process for the version you deploy | Confirm how the Sovereign edition delivers updates to isolated networks |
| Slack migration path | Built-in importer for full Slack exports; split files under 15 MB; rebuild integrations afterward | mmetl converts the Slack export; users, channels, threads and attachments move, integrations do not | Matrix bridges can keep Slack channels connected during a phased cutover; confirm bridge support in isolation |
| Cloud services that stop working offline | Push notification gateway, Marketplace and Omnichannel integrations stop when a version reaches end of life | Confirm which features depend on external services in an air-gapped install | Confirm which Element Call and push features need outside connectivity |
When Rocket.Chat's Government and Defense plans fit better than Mattermost Enterprise Advanced
Choose Rocket.Chat over Mattermost for a disconnected network only when the deciding factors are contractual and operational, not feature checklists. Both vendors list air-gapped deployment as a paid capability: Rocket.Chat's Government and Defense plans cover on-premises, air-gapped and sovereign deployments, while Mattermost places air-gapped deployment in Enterprise Advanced. Ask each vendor for the written license terms that apply to a disconnected install, including who may receive offline updates, how license keys are validated without a licensing server, and whether support is delivered on site or only through a remote channel that your network may not reach.
Read the license of the code you will actually receive. Rocket.Chat's repository is MIT licensed outside its enterprise directories, while code under the ee directories and apps/meteor/ee is covered by Rocket.Chat's enterprise license. A paid build therefore mixes two licenses, and your legal and accreditation teams should confirm which files fall under which terms before you accept an offline bundle. Mattermost's source is AGPL v3.0 or a commercial license from Mattermost, Inc., which raises its own questions for a closed network that distributes internally modified builds. Get the answers in writing before comparing price.
Then weigh the operating model your team already runs. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and a three-member replica set is strongly recommended for high availability, so a team without MongoDB operators will carry a new database discipline into the enclosure. Test the Slack import path too: Rocket.Chat's Import tool accepts full Slack exports, while Mattermost uses mmetl and mmctl. Confirm which data classes you must carry across the boundary, because a successful import in a lab does not prove the same procedure works with your offline packaging rules and your upgrade cadence of six months for standard releases.
How to deploy Rocket.Chat on a disconnected network
This sequence takes a Rocket.Chat deployment from a written entitlement check to a tested offline upgrade, with each step naming what the security and network teams must supply.
Confirm the plan and air-gap entitlement in writing
Before any build work, confirm with Rocket.Chat which paid plan covers air-gapped deployment, since Starter does not include it. Procurement and the CIO's office own this step, and the answer should be a written statement naming the plan, the deployment model and the support terms that apply offline. Ask whether the plan includes the multi-instance or microservice designs you may need as user counts grow, because the reference architectures list those as paid features. The step is done when the entitlement is on file and the security team has signed off on the deployment model.
Stage container images and Helm charts in a private registry
Your platform team downloads the Rocket.Chat container image, the MongoDB image and the Helm chart on a connected staging host, scans them, and loads them into a registry inside the disconnected network. The security team verifies the integrity and provenance of each artifact before it crosses the boundary, which is the control NERC CIP-013-2 describes for vendor software and patches in regulated environments. The step closes when every image the deployment references resolves from the internal registry and a test pull succeeds from a node with no internet route.
Build the Kubernetes cluster without internet access
The platform team builds the cluster offline using kubeadm. On the staging host they run kubeadm config images list and kubeadm config images pull to fetch control plane images in advance, then push them to the private registry. During kubeadm init they pass the --image-repository flag so the cluster pulls from the internal registry. Network engineers confirm that egress to the internet is blocked from every node. The step is complete when all nodes report Ready and the cluster can schedule a test pod from the internal registry alone.
Deploy MongoDB as a three-member replica set
The database team deploys MongoDB 8.0 or later as a three-member replica set, which Rocket.Chat 8.x requires and which the system requirements strongly recommend for high availability. The team places members on separate nodes and storage so one failure does not take the replica set down, and confirms that the replica set has a primary and two secondaries. Backup owners set up snapshots or dumps stored inside the network. The step is done when rs.status() reports a healthy primary and both secondaries, and a failover test completes without data loss.
Install Rocket.Chat from the internal Helm chart
The platform team installs Rocket.Chat using the staged Helm chart and images, pointing values to the internal registry and the MongoDB replica set. Node.js is bundled in the official image, so no separate runtime is pulled from outside. Application owners set the public hostname, TLS certificates from the internal certificate authority and the mobile and desktop client endpoints. The step closes when the login page loads over TLS from inside the network and an administrator account can sign in.
Connect LDAP or SAML from the directory
The identity team configures LDAP or Active Directory authentication, or SAML single sign-on, against the directory the organization already runs inside the network. Starter includes LDAP and SSO, but the paid plan adds SAML user group mapping that many classified and regulated environments use for role assignment. Security reviews which groups map to administrators and which to standard users, and confirms that multi-factor authentication is enforced. The step is done when a test user from each group signs in and receives only the expected roles.
Import the Slack export through Manage, Workspace, Import
The workspace owner splits the Slack export into files under 15 MB, as the Rocket.Chat import documentation recommends, then uploads them through Manage, Workspace, Import. Public and private channel contents come across only if the export included them, which depends on the Slack plan and approval described in the export documentation. Integrations, bots and webhooks must be rebuilt afterward. Reviewers check channel counts, user mapping and a sample of threads and attachments. The step is done when the import report shows no failed records and the sample checks pass.
Rehearse one offline upgrade before go-live
Because standard releases are supported for six months and LTS releases for twelve, and unsupported versions lose mobile client connectivity, the operations team must prove it can upgrade without internet access. They stage the next release's images and chart on the connected host, carry them across the boundary through the same integrity check, apply the upgrade in a test copy of the environment and restore a backup into it. The step is complete when the test upgrade finishes, clients reconnect and the runbook records every command used.
What stops working offline and what forces regular upgrades
Rocket.Chat states that some services depend on cloud infrastructure it operates. Once a version reaches end of life, or when the server has no connectivity, those services stop working. The ones named in the vendor's version durability documentation include the push notification gateway, Marketplace and Omnichannel integrations. Each of these changes how users, bots and customer conversations behave, so the disconnected design needs a decision for each one before go-live.
- Push notifications: Mobile alerts routed through the push notification gateway will not arrive on an isolated network. Plan how users will learn of new messages, such as in-app checks or an internal notification service.
- Marketplace apps: Apps installed from the Marketplace may need outside connectivity to install, update or call a vendor service. Pre-stage any app you need and test it on the isolated network.
- Omnichannel integrations: Customer-facing channels that depend on outside providers will not function. Confirm whether your use case relies on them at all.
- Mobile and desktop clients: Confirm with the vendor which client versions connect to a disconnected server and how they are distributed to users.
- Replacement planning: For every feature you use, record a fallback, an internal owner and a test date.
Inventory the features your teams actually use, then test each one on the isolated network before relying on it.
Rocket.Chat supports standard releases for six months and LTS releases for twelve months. After the end of life date, a version receives no security or bug fixes. Because an air-gapped system cannot pull patches on its own, every upgrade is a transfer of software into the isolated boundary, followed by testing and a rollout. The support window therefore sets the pace of the operating budget, not just a vendor policy.
- Six-month standard releases: Standard lines need an upgrade roughly twice a year to remain supported, which means two offline cycles per year on that track.
- Twelve-month LTS releases: LTS lines halve the cycle frequency but still require a planned transfer, test and rollout every year.
- Client compatibility: Unsupported versions may lose the ability to connect with the official mobile and desktop clients, so an expired server can break daily use even without a security event.
- Repeatable cycle: Build a documented procedure covering package transfer, integrity checks, staging tests, backups and rollback so each upgrade is routine.
- Budget components: Account for staff time, a staging environment that mirrors production, and the MongoDB replica set upgrade alongside the application.
Confirm the current support dates for the version you plan to deploy with Rocket.Chat before setting the upgrade calendar.
The operating model for a disconnected deployment combines the cloud dependencies and the upgrade cadence into one routine. Each feature that stops working and each support deadline must map to a named owner, a test and a date in the operations calendar. Without that mapping, a disconnected server tends to drift into an unsupported state while still appearing to work.
- Owner per feature: Assign each cloud-dependent feature to an owner who tests it after every upgrade.
- Transfer controls: Each package moved across the boundary should be checked for integrity and authenticity before it enters the network, consistent with the supply chain expectations in NERC CIP-013-2 where that standard applies.
- Staged rollout: Test every release on a staging system before production, including MongoDB compatibility.
- Rollback path: Keep a tested backup and a documented return path for each upgrade.
- Lifecycle calendar: Track support end dates for the Rocket.Chat line and the MongoDB version together.
Review the Rocket.Chat version durability documentation and your own test results with the vendor before committing to a support plan.
Evidence assessors and accreditors ask for under this constraint
Disconnected deployments are judged on what can be shown, not on what was intended. The records below connect the software that crosses the boundary, the database that stores the messages, and the people who administer it. DeployOpen prepares these records as part of the implementation, while independent assessors and accreditation bodies make the determinations.
Software bill of materials and image inventory
Every package, container image and Helm chart carried across the boundary should appear in a written inventory with its name, version and source. For Rocket.Chat, that includes the server image, the MongoDB 8.0 or later packages, and any Node.js runtime bundled in the official Docker image or Helm chart. Ask the assessor which inventory format they accept, and confirm that the inventory matches the exact versions installed, since patch releases such as 8.6.3 and 8.5.4 were published on October 16, 2026 for older supported lines.
Integrity verification records at the boundary
Each transfer into the isolated network needs a record showing how the artifact was checked before it was loaded, such as published checksums or signatures, the hash values recorded, and who approved the import. This is the evidence behind the supply chain control in NERC CIP-013-2, which asks procurement processes to address verification of software integrity and authenticity. Keep the transfer log separate from the package itself so that a failed check can be traced to a specific media item.
MongoDB replica set configuration and backup tests
Rocket.Chat 8.x runs on a MongoDB replica set, and a three-member set is strongly recommended for high availability. Assessors will want the configured member count, the election settings, the storage location and the results of restore tests from backups taken inside the enclave. A backup that has never been restored is not evidence of recoverability, so record the date, the restored host and whether message counts matched.
Offline upgrade runbook with dated run records
Support windows of six months for standard releases and twelve months for LTS releases mean the boundary will need regular upgrades. Keep a runbook covering the offline image transfer, the backup taken before the change, the upgrade steps and the rollback path, and log the date and operator of each run. Once a version reaches end of life, cloud services such as the push notification gateway stop working, so the log should also show when each version was retired.
Administrator access logs and MFA records
Assessors commonly test whether privileged accounts are individually identified, protected by multi-factor authentication and reviewed. Export the list of administrator accounts, the MFA enrollment status for each, the authentication logs, and any change to roles or the SSO and LDAP settings. Confirm with your assessor which control identifiers the records must map to, and check that Rocket.Chat's audit and session records are kept inside the enclave.
Slack export inventory and migration gaps
The migration record should state what came out of Slack, what landed in Rocket.Chat, and what did not. Slack's export plan decides whether private channels and direct messages were available at all, and Rocket.Chat's importer takes full Slack workspace exports, so the inventory should name the export type, its date and the file count. List the integrations, bots and custom emoji that were not carried over, and the owner of each rebuild task, so the gap is documented rather than discovered later.
What do buyers ask before hiring help for a disconnected chat deployment?
What drives the cost of a disconnected Rocket.Chat deployment?
The cost is driven by four components: the Rocket.Chat plan, infrastructure, MongoDB operations and migration and admin time. The plan is the only part quoted by the vendor. Rocket.Chat's Commercial, Government and Defense plans are priced by quote, and air-gapped deployment is not available on the free Starter plan, so the plan fee is a recurring line item you must confirm directly with the vendor. Infrastructure, MongoDB replica set hosting and staff time are paid to your own suppliers or internal teams. Ask any implementation partner for a written quote that lists one-time work (design, installation, migration, hardening, documentation) separately from recurring work (upgrades, backups, monitoring, retainers).
Can our team run a disconnected Rocket.Chat deployment without outside help?
Yes, if your team already runs MongoDB replica sets, Kubernetes or Docker in controlled networks and can plan offline package transfers. The harder parts are the upgrade cadence and the offline media process. 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 fixes. Each upgrade in an isolated network needs staged media, checksums and a tested rollback. Assess your staff against those tasks and decide whether you want to keep that work in-house or buy a retainer.
How long does a fixed-scope engagement for an air-gapped chat server take?
The duration depends on the scope you agree in writing, not on a fixed template. A single-instance deployment for up to 500 concurrent users, built on one MongoDB replica set, has a different workload from a multi-instance design with NATS, which Rocket.Chat's reference architectures suggest above 500 users, or a Kubernetes deployment with the official Helm chart, which they suggest above 5,000. Other scope drivers include the number of integrations, the directory and SSO setup, the size of the Slack history to migrate and how many approval rounds your security office requires. Ask for a timeline tied to each deliverable and milestone, and confirm which dependencies sit with your team.
What must our organization provide before an engagement starts?
Expect to supply the network diagrams showing the isolated boundary, the approved list of hosts and ports, the directory details for LDAP or Active Directory, named staff for operations and security review, and the approval path for software that will cross the boundary. You should also provide the transfer process for offline media and the names of the people who sign off each release. For the software supply chain, your procurement and verification steps for vendor packages and patches should be documented, since NERC CIP-013-2 addresses integrity and authenticity verification for vendor software in that way. Confirm each item with your security office before scoping starts.
Can all of our Slack history move into a self-hosted Rocket.Chat server?
Rocket.Chat imports full Slack workspace exports, Slack users from CSV and messages through its built-in importer, but the Slack export plan decides what you can get out. Public channels can be exported on every Slack plan, while private channels and direct messages require a Business+ or Enterprise plan, and custom exports by member or conversation are Enterprise-only. Rocket.Chat recommends splitting large exports into files under 15 MB. Slack Free also deletes content older than one year, so history beyond that window may already be gone. Integrations and bots must be rebuilt after import, so plan that work as a separate item in the quote.
What does a retainer cover after the Rocket.Chat server is live?
A retainer covers ongoing work after go-live, such as applying upgrades when Rocket.Chat releases new versions, testing offline update packages, verifying backups, reviewing logs and managing MongoDB maintenance. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. The retainer scope, response expectations and the frequency of upgrade cycles should be written into the agreement. Because Rocket.Chat says unsupported versions may also lose the ability to connect with official mobile and desktop clients, confirm in writing how quickly your upgrades will be planned and tested against that support window.
Which cloud features stop working on a disconnected Rocket.Chat server?
Several cloud-connected services stop working once a version reaches end of life, and some depend on internet access regardless of version. Rocket.Chat's version durability documentation names the push notification gateway, Marketplace and Omnichannel integrations as services that stop working when a version is unsupported. Your engineers should test each feature you plan to use in the isolated network, confirm which ones need outbound connections, and document any replacements. Ask your implementation partner for a written list of disabled features and the test results for each one before cutover.
Does DeployOpen certify that our disconnected chat deployment is compliant?
No. DeployOpen plans, implements, hardens, documents and supports the self-hosted platform and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask your implementation partner which evidence they will prepare, such as configuration records, access settings, backup logs and change records, and confirm with your assessor which items they need before the assessment begins.
How DeployOpen deploys Rocket.Chat under an air-gap constraint
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a Rocket.Chat deployment on a disconnected network, the work starts with a written scope that fixes which plan, MongoDB topology and offline update path the environment needs.
How we scope
- Confirm which Rocket.Chat plan covers the air-gapped deployment before any build work starts, since it is a paid-plan capability.
- Record the expected concurrent users to choose between a single instance with a MongoDB replica set and a multi-instance design.
- Agree in writing which cloud-dependent features, such as the push notification gateway, will be disabled or replaced.
How we build
- Stand up a MongoDB 8.0 or later replica set inside the enclave, with three members where high availability is required.
- Stage container images, Helm charts and dependencies through an approved transfer process, with each package checked before it crosses the boundary.
- Configure SSO, LDAP or Active Directory, multi-factor authentication and retention settings to match the client's existing identity controls.
How we hand over
- Deliver runbooks for offline upgrades, MongoDB backup and restore, and the version support windows the client must track.
- Document evidence for access control, software integrity checks and change records to support the client's own compliance assessment.
- Test backup restoration and a sample offline upgrade with the client's operators before the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial build.
- Plan each Rocket.Chat upgrade around its six-month standard or twelve-month LTS support window, with the transfer process repeated for every release.
- Confirm with the client who owns each recurring task, including patch intake, key rotation and periodic restore tests.
