Microsoft Teams alternative for air-gapped networks

Teams depends on Microsoft's cloud, so disconnected networks need a self-hosted chat stack with an offline install, update and push path. Here is which options fit and how to deploy them.

On this page

Why a Microsoft Teams alternative for air-gapped networks starts with the boundary

Start by confirming which chat and meeting stacks can run with no internet path at all, because for most of them the answer depends on the edition you buy. On a network with no route to Microsoft 365, Teams is not an option in any form, so the decision is between self-hosted platforms that were designed or licensed for disconnected operation. Air-gap support is often a paid-edition feature rather than a default: Mattermost lists air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from the free Starter plan, and Element Server Suite offers a separate Sovereign edition for air-gapped deployments. Before you shortlist anything, ask each vendor in writing which edition covers disconnected installs, which components are included, and whether the license terms allow operation with no license server reachable from your network.

At a high level, the four options in the air-gap set differ in shape. Mattermost Enterprise Advanced is a single-binary chat server backed by PostgreSQL that suits a team wanting a familiar channel model with SSO and compliance features in the paid tier. Element Server Suite Sovereign pairs Synapse with Element clients for Matrix-based chat and calls, and is the option to evaluate if federation control and open protocols matter to you. Rocket.Chat Government targets public sector and defense buyers who need on-premises and air-gapped operation with a vendor-supported plan. Jitsi is open source and self-hosted for video meetings, but it is a meeting tool rather than a full chat platform, so it usually sits beside one of the chat servers.

Your boundary also sets the review scope. Under NERC CIP-013-2, supply chain procurement processes must address verification of software integrity and authenticity for vendor software and patches, which applies directly to every package you carry across an isolated boundary. Ask each vendor how it signs releases and how you can verify artifacts offline before they enter the enclave. Confirm with your compliance lead which framework governs your network, since the controls that apply to a power utility, a defense contractor and a research institution differ, and the chat platform you pick must fit that framework's evidence requirements.

What an air-gapped chat deployment must satisfy

A disconnected chat deployment is judged less by its feature list than by whether it can start, run, patch and be audited without a path to the internet. The six requirements below connect the platform choice to the controls your assessors will ask about.

No runtime cloud dependency

Confirm that the chat server, its database, file storage, push relays and any identity provider run entirely inside your enclave. Any component that phones home for licensing, telemetry, fonts, maps or time synchronization will fail or silently degrade on an isolated segment. Ask the vendor to list every outbound endpoint the product contacts in its air-gapped configuration, and test that list from a network with no route out. Buyer responsibility: you define the boundary and verify the test.

Offline container and package images

Every image, package and rule set the platform needs must be pulled in advance on a connected staging system, then loaded into a private registry or package mirror inside the boundary. Kubernetes shows the pattern: control plane images can be listed and pulled ahead of time, then pointed at a private registry. Ask whether the vendor publishes complete offline bundles for each release, and whether the bundle includes dependencies such as PostgreSQL. Buyer responsibility: building and maintaining the mirror.

Verified software carried across the boundary

NERC CIP-013-2 expects supply chain procurement to address verification of software integrity and authenticity for vendor software and patches. In practice, each transfer into the enclave needs checksums or signatures checked against a value obtained from the vendor, recorded in a transfer log, and approved by the owner of the system. Ask which artifacts are signed, how signatures are published, and how your team validates them offline. Buyer responsibility: the transfer procedure and its evidence.

Controlled remote access

If the network is in scope of NERC CIP-005-7, all interactive remote access to high and medium impact BES Cyber Systems must pass through an Intermediate System, use encryption and multi-factor authentication, and allow detection and disabling of active vendor sessions. A chat platform that vendors support remotely needs the same discipline. Confirm whether the vendor's support path can be closed entirely, and how you would log and terminate a vendor session during an incident. Buyer responsibility: scoping the system and operating the access path.

Documented update path

Offline systems do not receive updates automatically, so an update path has to be designed before go-live. Mattermost publishes server releases in binary form on a monthly cadence and labels some as Extended Support Releases, which affects how long a version can stay in production. Define who downloads each release, who validates it, how database migrations are rehearsed, and how far behind the current version you will allow the system to run. Buyer responsibility: the schedule and the rehearsal.

Rollback and backup planning

Offline environments cannot easily re-fetch a missing package, so restore paths matter more. Matrix's Synapse upgrade notes warn that rolling back can be difficult because schema changes between releases are not always reversible, which makes a tested backup before every upgrade essential. Confirm which database and file store must be backed up together, and how a restore is verified inside the enclave. Buyer responsibility: backup scope, retention and restore tests.

Which self-hosted chat and meeting stacks run fully disconnected

This table compares four self-hosted options on how each runs without an internet path, which edition carries that capability, and its license. Read the air-gap row first, since it decides whether a stack is even in the shortlist, then check federation, high availability and migration for the operating trade-offs.

CapabilityMattermost Enterprise AdvancedElement Server Suite SovereignRocket.Chat GovernmentJitsi
Air-gapped deploymentListed in the Enterprise Advanced plan, not in lower tiersSovereign edition is built for air-gapped deploymentsGovernment and Defense plans support air-gapped deployments; the free Starter plan does notConfirm disconnected operation with the Jitsi project or your integrator before relying on it
Edition that carries the air gapEnterprise Advanced (paid, prepaid annual seat subscription)Sovereign (paid, separate from the free AGPL Community edition)Government or Defense (paid)Open-source self-hosted build; no paid edition confirmed in this research
LicenseAGPL v3.0 source or a commercial license from Mattermost, Inc.; compiled binaries MITSynapse under AGPLv3 with commercial licenses from ElementMIT outside enterprise directories; ee directories under Rocket.Chat enterprise licenseConfirm the license terms of the components you deploy
Updates offlineShip as a binary each month; confirm air-gapped update bundles in the Enterprise Advanced termsConfirm offline update and image delivery with Element for the Sovereign editionConfirm offline upgrade path and image delivery in the Government plan termsConfirm how container images and updates reach a disconnected network
Mobile push offlineConfirm how push notifications reach mobile clients on a disconnected networkConfirm push gateway options for disconnected mobile clientsConfirm push gateway options for disconnected mobile clientsConfirm mobile access and notification options in your environment
FederationNot a federated model; runs as a single self-contained server clusterFederation can be restricted with federation_domain_whitelist or disabled with an empty listNot a federated model; confirm with the vendorNot applicable to meeting servers
High availabilityEnterprise and Enterprise Advanced; needs shared file storage on every nodeSynapse scales with worker processes and Redis; plan database and Redis redundancyConfirm clustering in the Government planScales by adding video bridges; plan capacity per node
Migration from TeamsTeams Export APIs feed the bulk import format loaded with mmctlRequires extraction and mapping of teams to spaces and roomsNo Teams importer; Slack import route exists, so conversion is neededMeetings only; chat history does not move with Jitsi

How updates and patches reach a disconnected chat server

On an air-gapped network, an update is never pulled from the internet. It is built outside the boundary, scanned and checked for integrity, carried across on approved media, and then imported. Every component in that bundle, including the server binary, container images, database packages and plugins, needs its own intake check, which is the kind of software integrity verification that NERC CIP-013-2 asks procurement processes to address. Plan that intake step as recurring work, not a one-time install task.

Release timing sets how often that work comes around. Mattermost publishes server binaries on the 16th of each month, with v11.11 released on 2026-09-16 and v12.0 on 2026-10-16. Its Extended Support Release, v11.7, was released on 2026-05-15 with support ending 2027-05-15, and the previous ESR, v10.11, reached end of life on 2026-08-15. A disconnected operator may reasonably choose the ESR track to reduce how often bundles cross the boundary, but should confirm with Mattermost in writing whether the ESR is offered in the air-gapped edition and how security fixes are delivered between ESR cycles.

Synapse, the Matrix server, carries a different risk. Its upgrade notes warn that rolling back can be difficult because schema changes between releases are not always reversible, and that it drops support for Python and PostgreSQL versions once they reach upstream end of life. Before any import, take a verified database backup, test the upgrade on a copy of the environment, and record the PostgreSQL and Python versions each target release requires (Synapse 1.143.0 and later need PostgreSQL 14 or newer). For every product on your shortlist, ask the vendor for its offline update procedure, the supported path from your current version, and the rollback process, and file those answers with your change records.

What mobile push looks like without internet access

Mobile push on iOS and Android is delivered through the operating system push services run by Apple and Google. Unless Mattermost documents an in-network path for alerts, a phone on a disconnected network will not receive server-sent notifications by default. The server runs inside your boundary, but the last delivery step may leave it.

  • Relay dependency: Confirm whether Mattermost mobile push passes through a notification service that Mattermost operates, and whether a relay you host inside the network can replace it.
  • Tier coverage: Air-gapped deployment is listed in Enterprise Advanced on the Mattermost pricing page, so get written confirmation that push functions in that tier for disconnected use.
  • Outbound endpoints: Ask which hosts the mobile apps and server contact for push, and whether a proxy or allow list can restrict them.
  • Fallback behavior: Without push, confirm whether the apps sync in the background on disconnected devices or whether users must open the app to see new messages.
  • Lab proof: Test alerts on a lab network with the same device management policies and network controls you plan to use in production.

Confirm all of these in writing against the server version you will pin, because Mattermost publishes server binaries monthly and mobile app versions move separately.

How to deploy a chat stack inside an air-gapped network

This sequence takes a chat platform from an empty isolated network to a tested, single sign-on enabled pilot, with every image and package verified before it crosses the boundary and a cutover plan that uses Teams export paths only where your licenses allow.

  1. Build the private cluster baseline

    Your platform engineers prepare the Kubernetes or virtual machine baseline on the isolated network. For Kubernetes, they generate the control plane image list with kubeadm, pull those images on a staging host that has the approved media, and point kubeadm init at your private registry with the image repository flag. Done means the cluster initializes and every node reports ready without any outbound route to the internet.

  2. Mirror container and package images

    Your staging team pulls each chat, database, storage, identity and operating system image, plus the Linux packages and language dependencies they need, into a controlled staging environment. They record each artifact with its version and digest in a bill of materials. Done means every item the platform references exists in your private registry or package repository, and the list matches the vendor release you chose.

  3. Carry and verify artifacts across the boundary

    Security engineers move the approved media across the boundary under your transfer procedure. Before anything is loaded, they verify checksums and signatures against the vendor's published values and scan the artifacts with the tools your authorization process requires. This step supports the software integrity and authenticity expectations in NERC CIP-013-2 where that standard applies. Done means each artifact has a signed record of its hash and verification result.

  4. Install PostgreSQL and file storage

    Database administrators deploy PostgreSQL, which is the production database for Mattermost and is required for current Synapse releases, with backups configured inside the enclave. Storage engineers provision shared file storage that every application node can mount, such as NAS or an S3-compatible store, since local file storage will not work for clustered Mattermost. Done means a test write from one application node is readable from another and a restore from backup succeeds.

  5. Configure single sign-on and certificates

    Identity engineers connect the chat platform to your directory through the supported protocol, such as SAML or OpenID Connect, and confirm that users, groups and deprovisioning behave as expected. Certificate owners issue internal certificates from your private certificate authority and install the trust chain on every client device. Done means a test user signs in with multi-factor authentication, a disabled account loses access, and the browser and client show no certificate warnings.

  6. Run a pilot with a bounded group

    The project owner selects a small group of users and a limited set of channels or rooms, then tests messaging, file sharing, search, notifications and any calling service against the written acceptance criteria. Administrators check logging, retention settings and the procedure for applying an offline update. Done means the pilot group has signed off on each criterion in writing and every issue found has an owner and a fix or accepted risk.

  7. Plan cutover and any Teams data move

    The migration lead sets the cutover date, communicates it, and decides which Teams history to bring over. Microsoft Teams Export APIs require admin-approved application permissions and an active Teams license on each exported user, so confirm with your Microsoft administrator whether that access is available before you commit to an import. Done means a signed cutover plan lists the data scope, the license basis for any export, the rollback steps and the people who approve each stage.

Evidence that auditors and regulators ask for

Auditors and regulators rarely accept a claim that a system is isolated. They ask for records that show what crossed the boundary, who changed what, and whether recovery works. The cards below cover the evidence most often requested for a disconnected chat and meeting stack, with DeployOpen preparing the material and independent auditors issuing any assessment.

Software bill and integrity checks

Keep an inventory of every package, container image and model or rule file carried across the isolated boundary, with its version and a checksum or signature recorded at import time. NERC CIP-013-2 expects supply chain procurement to address verification of software integrity and authenticity for vendor software and patches, so each transfer needs a documented verification step. Ask each vendor which signatures and checksums they publish for offline bundles. Confirm that the inventory covers Mattermost, Element Server Suite or Rocket.Chat components, plus their PostgreSQL, Redis and operating system dependencies.

Change records for offline updates

Offline updates arrive as media, not as pulls from a repository, so each upgrade needs a ticket, the release notes reviewed, a test in a staging enclave and a rollback plan. Record the exact version applied on each node and the date it went live. Mattermost publishes server releases on a monthly cadence and separates Extended Support Releases, so the change record should state which release line the organization follows. Synapse upgrade notes warn that rollback can be difficult because of schema changes, so restore points must exist before every change.

Access logs and remote session controls

Where a vendor or integrator needs remote access into the enclave, NERC CIP-005-7 requires Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication, and requires methods to detect and disable active vendor sessions. Keep logs of every session start, end and privilege grant, and retain the authentication records from the identity provider. Confirm how your chat platform's admin audit logs are exported and whether they are retained for the period your program requires.

Backup and restore tests

A backup that has never been restored is not evidence of recovery. Keep dated restore tests that rebuild the chat database, the file store and the search index on separate hardware inside the enclave, then compare message counts and sample attachments against the source. Mattermost high availability requires shared file storage on each node, so test that the file store and database restore together. Record the elapsed time of each test and the defects found, and do not treat a backup job's success message as proof of restore.

Architecture diagram of the boundary

Auditors need one diagram that shows every system inside the isolated network, every data path that crosses its edge, and every point where media or files are imported. Label the chat servers, database and file storage, the identity provider, the admin workstations, the transfer station and any monitoring node. Include the controls at each crossing, such as the Intermediate System for remote access. Review the diagram after each upgrade, since a new federation listener, bridge or SSO connection can open a path that the earlier version did not have.

Vendor and integrator responsibility records

Keep a written record of who supplied each component, who signed off on its verification, and who is responsible for patching it. For air-gapped chat, this usually includes the platform vendor, the operating system provider, the database maintainer and the integrator that performed the installation. Confirm with each vendor whether its air-gapped license or edition carries contractual support for offline updates, since the paid tier is often the one that includes air-gapped deployment. DeployOpen can prepare these records as part of a fixed-scope engagement, but the responsibility matrix must be signed by your organization.

Questions buyers ask before choosing an air-gapped chat stack

What drives the total cost of an air-gapped chat deployment?

The biggest cost drivers are the licence tier, the hardware or cloud capacity inside your boundary, the people who run the stack, and the update process you build for offline media. Licence cost is usually one of several line items, and for Mattermost the air-gapped deployment sits in the Enterprise Advanced plan, so the tier you need is the first thing to confirm. Infrastructure recurs every year, while design, integration, hardening and the first migration are one-time costs. Ask any quote to separate these, to list the licence tier and its term, to state who performs each task, and to show how patches and offline bundles will be verified before they cross the boundary.

Can our own team deploy and run an air-gapped chat server?

Often yes, if your team already operates Linux, PostgreSQL, reverse proxies and a private container or package path. Mattermost runs as a single Linux binary with PostgreSQL as its database, which keeps the moving parts few, but high availability adds shared file storage, redundant application servers and load balancers, and that requires skills your team may not have. Matrix with Synapse adds Redis for workers and PostgreSQL version rules. Check honestly whether you have people for identity integration, backups, offline patching and on-call support. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own networks, under a written scope, so the choice can be a fully in-house build, a partial handover or a fixed-scope engagement.

How long do a pilot and cutover take in an isolated network?

No supplied figure fixes this, so confirm it against your own environment rather than a generic estimate. The duration depends on how many channels and users are in scope, whether you need history migrated, how many identity providers and approvals sit in the path, and how often you can move software across the boundary. Ask the implementation partner to break the timeline into scope agreement, build inside an isolated test enclave, pilot with a limited user group, migration rehearsal and cutover, and to name who approves each step. Deployments are typically agreed as fixed scope in writing before work starts, so the written plan is the document to compare.

What does the work need from our side?

Expect requests for access to a staging network, named owners for identity and directory integration, a decision on data retention, and people who can approve media transfers into the boundary. Security and compliance staff will need to review the design and the evidence trail. Engineers should supply current versions of the operating system, database and container runtime that your change process allows. Ask for a responsibility matrix in the scope document, listing what your staff must provide, what the vendor or partner provides and what the independent auditor covers, since DeployOpen prepares systems and evidence but does not issue audit reports or attestations.

Are Mattermost and Rocket.Chat air-gapped licenses priced by seat?

Mattermost sells Professional, Enterprise and Enterprise Advanced plans as prepaid annual subscriptions based on the number of seat licenses, and its pricing page lists no public prices, so the seat count and term must come from a sales quote. Rocket.Chat offers Commercial, Government and Defense plans that support on-premises, air-gapped and sovereign deployments, and its free Starter plan excludes air-gapped use. Confirm with each vendor whether the air-gapped entitlement is priced per seat, per deployment or by another measure, whether it includes support and update channels, and how the license is renewed when your network cannot reach the license server.

How does Element Server Suite Sovereign differ from Community?

Element Server Suite comes in a free AGPL Community edition that includes Synapse and Element Call, a Pro edition with Synapse Pro, and a Sovereign edition built for air-gapped deployments. The Community edition is the open-source starting point, while Sovereign is the paid option for disconnected networks. Element positions the Community edition for non-professional use and evaluations, so a production air-gapped deployment should be checked against that positioning. Ask Element which components, support terms, update channels and offline bundle formats the Sovereign edition adds, and whether Synapse Pro features are included.

What breaks first when updates arrive by offline media?

Updates that depend on the internet, such as package mirrors, container pulls and license checks, fail first, so plan an offline repository before go-live. Synapse warns that rolling back can be difficult because of database schema changes between releases, so take a verified backup before every upgrade and rehearse the rollback. Mattermost publishes server releases on a monthly cadence and marks Extended Support Releases, so pick a branch with support dates that outlast your change window. Mattermost also requires shared file storage that works across nodes in a cluster. Verify the integrity and authenticity of every package crossing the boundary, as NERC CIP-013-2 expects for vendor software and patches in its scope.

Does a self-hosted chat stack meet NERC CIP requirements by itself?

No. A chat platform is one component, and compliance depends on how the whole environment is designed and evidenced. For example, NERC CIP-005-7 requires that Interactive Remote Access to high and medium impact BES Cyber Systems passes through an Intermediate System with encryption and multi-factor authentication, and that active vendor sessions can be detected and disabled. The chat server must sit behind those controls, not replace them. Ask your compliance lead and the implementation partner to map each control to a configuration, a log source and an owner, then have the independent auditor assess the result.

Choosing between Mattermost, Element and Rocket.Chat for a disconnected network

Start with the scope of the product, because it decides the rest. If the network needs chat only, Mattermost and Rocket.Chat are the natural fits, since both are built around channels, threads and file sharing. If chat and meetings must work together on the isolated network, Element with Element Call and a self-hosted LiveKit server covers both in one Matrix-based stack, but it adds more components to certify and operate. Jitsi can carry meetings alongside any of the three chat options. Write down which of these two needs is mandatory before comparing licenses, because a meeting requirement changes the server count and the operations workload more than any feature table will.

Next, decide whether the network must federate with other organizations or with other isolated enclaves. Synapse, the Matrix server behind Element, supports federation controls such as federation_domain_whitelist, and an empty list disables federation entirely, so an enclave can be fully closed while keeping the option open. Mattermost and Rocket.Chat do not federate in the Matrix sense, so a multi-organization requirement points toward Element. Also decide on high availability. Mattermost high availability is available only on its Enterprise and Enterprise Advanced plans, and a cluster requires shared file storage on each node, such as NAS or an S3-compatible service. Local file storage will not work correctly and risks corrupting files. Ask your storage team whether that shared tier is inside the enclave before you commit to clustering.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For a Microsoft Teams alternative for air-gapped networks, the work starts with which chat platform fits the isolation, licensing and offline update model, then carries that choice through build, handover and ongoing support.

How we scope

  • Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
  • The written scope names the chat platform, edition, user population, and which Teams data, if any, is extracted.
  • Scoping confirms which license tier includes air-gapped deployment, since that feature is paid on several platforms.

How we build

  • Build covers installing the chat server and database inside the isolated network with no internet path.
  • Container and package images are staged through an approved transfer process so each artifact can be checked before it crosses the boundary.
  • Single sign-on, backups and offline update procedures are configured and tested against the client's own identity provider.

How we hand over

  • Handover includes architecture, configuration and runbooks for operating the platform without internet access.
  • Documentation records the evidence for controls such as software integrity checks, so compliance teams can review it with their assessor.
  • DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover.
  • Retainers can cover staging and verifying each offline release before it is loaded into the isolated environment.
  • Security testing of the deployed platform can be scoped separately, including user access and administrative paths.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.