Team chat in air-gapped networks

Team chat in air-gapped networks: why the edition decides the build

A team that must keep messaging on a disconnected or classified network cannot rely on public SaaS chat or on public push gateways, so the platform has to run entirely inside the enclave. The core question is not which chat product you like best. Air-gapped use is often a paid-edition capability, so the edition you can license determines what you can build. Mattermost lists air-gapped deployment in Enterprise Advanced, and Rocket.Chat excludes it from its free Starter plan, which is why the edition check comes before any feature comparison. Matrix is a different case: Element Server Suite has a free AGPL Community edition, a Pro edition and a Sovereign edition for air-gapped deployments, so confirm with Element which tier covers your network class before you commit.

On the short answer, Mattermost and Rocket.Chat both need a paid tier before they can run air-gapped, while Matrix through Element needs its Sovereign tier for the same purpose. Four decisions follow from that and shape the rest of the build. The first is licensing: confirm in writing which edition covers air-gapped use, which features it includes (SSO, high availability, FIPS, audit trails) and whether the vendor's license terms allow your enclave's update model. The second is push notifications, because mobile clients normally depend on a vendor gateway that an isolated network cannot reach. The third is upgrades, since Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and Mattermost ships a server release monthly, so you need an offline upgrade path that keeps pace. The fourth is federation, which you should switch off or restrict to named domains by default.

Which requirements shape a disconnected chat deployment

This table maps each requirement that applies to chat on a disconnected network to what it asks of the build and what an assessor will expect to see. Read each row as a design input: the requirement determines the artifact pipeline, push path, logging and retention design that follow from it.

Requirement	What it asks for	What it means for the build
Records retention (SEC Rule 17a-4(b)(4))	Broker-dealers preserve originals of business communications, including inter-office messages, for not less than three years	Plan retention and export inside the enclave, with copies that cannot be altered by ordinary administrators and a tested restore path for archived messages and files
HIPAA transmission security (45 CFR 164.312(e)(1))	Technical measures guard against unauthorized access to ePHI sent over a network	Encrypt traffic inside the enclave, restrict guest and federated access, and confirm that mobile and desktop clients enforce the same controls
HIPAA audit controls (45 CFR 164.312(b))	Systems holding ePHI record and allow review of activity	Keep audit logs of logins, administrative changes and message or file access on enclave storage, and forward them to a local log store that is reviewed
Software integrity for carried packages (NERC CIP-013-2)	Procurement processes verify integrity and authenticity of vendor software and patches	Build an offline artifact pipeline that verifies checksums and signatures of server, plugin and container images before they cross the boundary, and records each transfer
No public push gateways	Mobile notifications normally route through vendor-hosted relays that the enclave cannot reach	Run a local push relay or accept in-app notifications only, and test how alerts behave on devices that have no route to the outside network
Offline upgrades against short support windows	Vendor support windows end on fixed dates, and out-of-support versions can lose client compatibility	Schedule upgrade bundles on a fixed cadence, rehearse them in a staging enclave, and budget time for transfer, verification and rollback
Federation and external connectivity	Disconnected networks usually need federation and bridges turned off	Disable federation and third-party bridges at the server level, then verify that outbound connections are blocked by network policy, not only by configuration
Access and network perimeter (NERC CIP-005-7 style)	Interactive remote access passes through a controlled intermediate system with strong authentication	Route administrator and vendor access through a monitored jump path, and keep the ability to disable active vendor sessions during an incident

Which editions license air-gapped use

Mattermost lists air-gapped deployment in its Enterprise Advanced plan on its pricing page. The lower plans do not carry that capability, so an air-gapped build that starts on a cheaper tier may need a plan change before go-live. Mattermost sells these plans as prepaid annual subscriptions based on seat licenses, and the pricing page lists no public prices, directing buyers to contact sales. The server binaries are MIT licensed, but the license terms of a plan govern what you may run in an isolated network.

Plan gate: Confirm in writing that your edition includes air-gapped deployment, not just the server binary license.
Seat-based pricing: Ask how seat licenses are counted for users, guests and service accounts.
High availability: Clustering is available only on Enterprise and Enterprise Advanced, so confirm whether your design needs it.
FIPS 140-3: Compliance is listed from Enterprise, which matters if your boundary requires it.
Release cadence: Mattermost publishes server binaries on the 16th of each month, so ask how offline updates are supplied to you.

Close by asking the vendor to confirm the air-gapped entitlement, the seat count basis and the support window for the release you will install.

Which chat platforms fit a disconnected network and why

Air-gapped chat is decided less by features than by licensing, storage, database and upgrade cadence. Each option below carries a different condition on the isolated network, and the confirmation step differs for each.

Mattermost on an isolated network

Mattermost runs as a single Linux binary backed by PostgreSQL, which keeps the footprint small to move across a one-way transfer boundary. Compiled binaries are MIT licensed, but the air-gapped deployment itself is listed under Enterprise Advanced, so the paid edition is a licensing decision, not a technical one. High availability needs shared file storage such as NAS or an S3-compatible service mounted on every node, and local disk will not work. Confirm the edition, the storage design and how each monthly release is validated before it crosses the boundary.

Rocket.Chat with a MongoDB replica set

Rocket.Chat's core is MIT licensed, but code under its enterprise directories follows a separate license, so confirm exactly which components your deployment uses. Version 8.x requires MongoDB 8.0 or later running as a replica set, and that database becomes an isolated-network dependency you must mirror, patch and back up. Air-gapped deployment, multi-instance designs and built-in failover sit on paid plans rather than the free Starter tier. Confirm that the support window fits your offline upgrade schedule, because unsupported versions lose security fixes and client compatibility.

Element Server Suite Sovereign

Element Server Suite offers a free AGPL Community edition, a Pro edition and a Sovereign edition built for air-gapped deployment, so the commercial edition is the one to evaluate for disconnected networks. Matrix keeps messages and rooms on infrastructure you control, which suits teams that need controlled federation and strong separation from public networks. Ask the vendor which components ship in the Sovereign bundle, how push notifications reach mobile clients without a public gateway, and how updates are delivered as offline packages.

Synapse self-managed with federation off

Synapse, the Matrix homeserver maintained by Element, is licensed under AGPL-3.0, which carries source-availability obligations if you modify it and distribute the result. For a disconnected network, the practical choice is to run Synapse with federation disabled so the homeserver talks only to clients inside the enclave. You then own the build, the container images, the database and every security patch, with no vendor edition to supply those for you. Confirm the licensing position with counsel and the release cadence you can keep up with offline.

How push notifications and upgrades work without public gateways

This sequence shows how a disconnected chat deployment gets mobile push, patches and version upgrades without depending on public cloud relays, and ends with an approved, signed upgrade bundle and a rollback that has been tested.

Confirm the push notification path for each client
Before the platform is selected or deployed, the architect and the chat vendor confirm how mobile and desktop notifications reach devices when the network has no route to public push gateways. Ask each vendor whether it offers an on-premises push relay, a customer-hosted notification service, or only a cloud gateway, and whether that gateway is included in the edition being bought. Rocket.Chat notes that after end of life a version loses cloud services such as its push notification gateway, so the answer must hold for the supported version line. The step is done when the written answer for each platform and each device OS is in the design record and has been checked against a test device inside the isolated network.
Map each vendor's support window to the upgrade calendar
The operations team builds a version calendar from the vendor's published release and support dates, not from memory. Mattermost releases server binaries on the 16th of each month and publishes support end dates per version. For example, v11.11 was released on 2026-09-16 with support ending 2026-12-15, while v11.7 is an Extended Support Release with support ending 2027-05-15. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. The output is a dated register of the running version, the next target version and the end-of-life date for each component, reviewed on a fixed cadence.
Stage and verify the offline upgrade bundle
On a connected staging network, the team downloads the target release, container images or binaries, database migration scripts, plugins and their dependencies, then computes checksums and verifies vendor signatures where the vendor publishes them. The bundle is moved across the boundary under the same process used for any software carried into the isolated network. The control that applies is the supply chain requirement in NERC CIP-013-2 for verifying software integrity and authenticity, which is used here as a reference model for any regulated environment. The step closes when the bundle manifest lists every artifact with its hash and the security team has signed off on it.
Test the upgrade and rollback in a mirrored environment
The team applies the bundle to a clone of production that has the same database engine, file storage, authentication settings and push configuration. Mattermost high availability depends on shared file storage on Amazon S3, an S3-compatible service or NAS, and Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, so the clone must match those topologies. The test runs the database migration, confirms that messages, files and SSO logins still work, checks that mobile clients still connect, and then restores the pre-upgrade backup to prove rollback. The step is done when the test record shows a successful upgrade and a successful rollback, with timings noted for the change window.
Approve the change and sign the bundle
The change advisory board reviews the test record, the bundle manifest, the rollback plan and the vendor's release notes for security fixes and breaking changes. Approval is recorded in the change system, and the approved bundle is signed with an internal key or stored with a signed checksum file so that production only accepts artifacts from this list. Where the vendor offers a paid edition with air-gapped support, the license entitlement is confirmed before approval. The output is an approved, signed upgrade bundle linked to a change record and a named rollback owner.
Apply the upgrade inside the isolated network
Operators apply the signed bundle in the production enclave during the approved window. The sequence is backup and snapshot first, then verification of the bundle hashes against the manifest, then the database migration, then application servers in an order that keeps the service available when high availability is in use. Post-upgrade checks confirm the service health endpoint, login through the identity provider, message send and receive, file upload and push delivery on a sample of devices. The step is done when those checks are logged against the change record.
Roll back on failed checks and record the outcome
If any post-upgrade check fails inside the agreed criteria, the operators restore the pre-upgrade snapshot and database backup and bring the prior version back online, using the rollback steps rehearsed in the test environment. The incident or change record captures the reason for rollback, the artifacts involved and the next attempt date. If the upgrade succeeds, the old bundle is retained for the period the organization's records and recovery policy requires. The output is either a confirmed production version with its support end date entered in the register, or a documented rollback that starts the next cycle.

Disabling federation and external connections safely

The first task in an isolated enclave is to switch off every path that reaches outside it, and to prove that each one is closed. For a Matrix deployment on Synapse, the most important setting is federation: a homeserver that can talk to other servers will try to resolve and contact them unless federation is disabled or restricted to an approved list of domains. Element's server products follow the same model, so the reader should confirm the current federation settings in the Synapse and Element documentation for the exact release in use, not rely on a default from an earlier version. For Mattermost and Rocket.Chat, the equivalent exposure is less about federation and more about outbound integrations: incoming and outgoing webhooks, slash commands, plugins, and any bridge that forwards messages to an external service. Each of these should be listed, reviewed and disabled by policy, with the reviewer confirming in writing which ones the enclave's business case still needs.

Next, cover the quieter outbound paths. App marketplaces, plugin catalogs and update checks try to contact vendor servers on a schedule, and telemetry or diagnostic reporting can send usage data by default. Push notification gateways are a separate case, because mobile push normally depends on a vendor-operated relay; the Rocket.Chat version durability documentation notes that cloud services such as its push notification gateway stop working after a version reaches end of life, which shows how much these features depend on vendor connectivity. Identity is the fourth path. Single sign-on and directory sync must point only at identity providers inside the enclave, and any fallback to a public identity service or a hosted SMTP relay must be removed. Document where every connection is disabled, then test from inside the enclave with a packet capture or egress firewall logs, looking for DNS queries and TCP sessions to addresses outside the approved list.

Treat this verification as a repeatable acceptance test rather than a one-time check. Each setting should be recorded with the release it was verified against, because the vendor defaults and feature names change between versions, and a monthly release cadence means the list can drift quickly. Ask the implementation partner to deliver the egress test results, the configuration baseline and a runbook for re-running the tests after every upgrade. The security team should also confirm that the same test catches a new integration added later by a user or administrator. An isolated network is only as strong as its least-reviewed connection, so the evidence should show both that the known paths are closed and that new ones are detected.

Deployment pattern for an isolated chat enclave

An air-gapped chat enclave is only as useful as the services around it. The four components below decide whether messaging keeps working when the network is cut off, and whether the enclave can later show what happened inside it. Each one needs a decision before the platform is installed, not after.

Directory and SSO without outbound calls

Users, groups and login must resolve from a directory inside the enclave, such as Active Directory or LDAP, with SAML or OIDC pointing at an identity provider that is also inside the boundary. Any setting that calls a public identity service, license check or update endpoint will fail or leak metadata. Confirm with the vendor which features, such as LDAP group sync and SSO, need outbound access and which work from local configuration alone.

Database tier sized for the platform

Mattermost stores its data in PostgreSQL, while Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set. The database is where message history, retention and audit records live, so backups must be taken and restored inside the enclave on a tested schedule. For Rocket.Chat, a three-member replica set is strongly recommended for high availability. Ask the partner how replica members are placed across failure domains and how restores are verified.

Shared file storage for high availability

A Mattermost high availability cluster needs shared file storage on an S3-compatible service or NAS mounted on every node, because local file system storage will not work correctly and risks corrupting files. Inside an air-gapped network this usually means an on-premises object store or a NAS that is itself replicated and backed up. Check that file storage, database replicas and load balancers fail over together, since a healthy application tier cannot serve files from a broken store.

Audit and log pipeline inside the enclave

Audit controls under the HIPAA Security Rule require hardware, software and procedural mechanisms that record and examine activity in systems holding ePHI, and similar expectations apply to regulated chat generally. Logs from the chat servers, database, file store and reverse proxy should flow to a collector inside the boundary, with retention and access rules set in writing. Confirm which audit events each edition produces, since tamper-evident audit trails are listed as a paid-plan capability for Rocket.Chat.

Evidence assessors ask for from an isolated chat system

This table maps each piece of evidence an assessor may request from an air-gapped chat deployment to the component that produces it and the gap to confirm before go-live. Read it as a checklist for the design phase, since several items exist only on paid editions or depend on your own export and log handling. DeployOpen prepares the systems, controls and evidence, but auditors and certification bodies issue the conclusions.

Evidence item	Produced by	What to confirm before go-live
Retention and export records	Retention policies and compliance export on the chosen edition's paid plan, with exports kept in the enclave	Confirm the edition includes retention and compliance export, and that exports are stored outside the chat database and tested for completeness
Audit trail of messages, files and sessions	Tamper-evident audit trails listed on Rocket.Chat paid plans, plus server and reverse proxy logs forwarded to your log store	Confirm which events the audit trail records, how it is protected from edits, and where it is retained for the period your rules require
Access and SSO configuration	Identity provider configuration exported from the chat admin console, directory sync settings and MFA policy records	Confirm SAML or OIDC settings, group mappings and MFA enforcement are versioned in change control and reviewed on a fixed schedule
Software integrity records for each carried artifact	Hash and signature verification logs for every container image, package and binary moved across the boundary, mapped to NERC CIP-013-2 supply chain procurement practices	Confirm who verifies each transfer, which signing keys are trusted, and where the verification record is stored for each import
Upgrade and patch history against support windows	Change tickets, offline upgrade logs and the version register showing each release against its published support end date	Confirm the upgrade cadence covers the shortest support window in use, and that the register records when each version reaches end of support
Federation and network configuration	Server settings disabling federation, firewall and egress rules, and records of any approved exceptions	Confirm federation is off in the configuration, the rule set is exported on each change, and any exception has a named approver and expiry

How much does air-gapped team chat cost and what drives it?

What makes air-gapped team chat more expensive than a standard self-hosted install?

The biggest difference is the edition. Air-gapped use is often a paid feature, so the platform license is the first cost to check. Mattermost places air-gapped deployment in its Enterprise Advanced plan, Rocket.Chat excludes it from the free Starter plan, and both are sold as prepaid subscriptions or quotes. Beyond licensing, you pay for servers and storage inside the isolated network, the staff who run the offline update process, and the work to validate every package carried across the boundary. Ask each vendor in writing which edition includes air-gapped rights, how seats are counted and whether the price is per year.

Which cost drivers grow with seat count and high availability needs?

Seat count drives subscription price for most paid editions, so confirm whether guests, bots and service accounts count toward the license. High availability adds cost in several places: Mattermost clustering is limited to Enterprise and Enterprise Advanced, it needs shared file storage on an S3-compatible service or NAS mounted on each node, and it requires redundant application servers, database servers and load balancers. Rocket.Chat's multi-instance and microservice reference architectures also require a paid plan and a MongoDB replica set of at least three members is strongly recommended. Each step up in concurrency adds infrastructure and staff time, so ask for sizing assumptions in the quote.

How much staff time does the offline update process take each month?

Staff time is often the largest recurring cost and it is easy to underestimate. Mattermost releases a new server version in binary form on the 16th of each month, and Rocket.Chat standard releases are supported for 6 months while LTS releases are supported for 12 months. Each release must be downloaded outside the network, scanned, validated and moved across the boundary, then tested before it reaches production. The effort depends on how many environments you run, how much custom integration code you maintain and whether the release process is documented. Ask a partner to show the upgrade runbook and the expected effort per cycle in the written scope.

Can our internal team run air-gapped chat without an implementation partner?

Many organizations can run it internally once the platform is built, but the first rollout usually needs skills that are scarce in one team. Your staff must handle identity integration, database and file storage design, backup and restore testing, certificate management, offline package handling and security review. Plan for at least one person who owns each monthly release and one who owns incident response for the chat service. A fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, backup, documentation and handover, after which you can decide whether to keep the platform in-house or retain ongoing support.

How long does an air-gapped chat rollout take and what changes the timeline?

No fixed duration applies to every environment, so ask for a written scope with a timeline before work starts. The main drivers are the number of networks in scope, whether the platform must connect to an existing identity provider, the storage design, how many integrations and migrations are needed, and how many approval cycles your security and change boards require. Migrating history from Slack or Teams adds work, and Rocket.Chat's import tools support full Slack workspace exports and CSV, while Mattermost data is migrated by converting its export into CSV. Ask the partner to list each milestone, the approvals it depends on and the acceptance tests.

What do we need to provide on our side for the engagement?

You need to provide approvals and access before implementation can start. The network team must define the isolated boundary, the data transfer path and the rules for moving packages in and out. The identity team must supply directory and single sign-on details, and the security team must approve encryption, audit logging, vulnerability handling and the software supply chain process. NERC CIP-013-2 is a useful reference for the supply chain control: it addresses verifying the integrity and authenticity of vendor software and patches, which is the discipline behind checking every package carried across an isolated boundary. Ask the partner for a list of inputs and owners in the written scope.

What happens when a chat version's support window ends on a disconnected network?

The platform keeps running, but you lose fixes and eventually compatibility. Rocket.Chat says that after end of life a version receives no security or bug fixes, cloud services such as the push notification gateway stop working, and unsupported versions may lose the ability to connect with official mobile and desktop clients. Mattermost publishes support end dates per release, for example v11.11 with support ending 2026-12-15, and Extended Support Releases run longer. On an air-gapped network, plan upgrades before the end date, because each jump needs a validated offline package. Ask vendors for their current support calendar and the upgrade path you would follow.

Can we turn off federation later without rebuilding the platform?

Usually yes, and it is a configuration change rather than a rebuild, but confirm it for your chosen platform and version. On an isolated network, federation is normally disabled from the start because there is no external partner to reach. If you later enable it, reversing that choice needs a review of retained data, user identities and any bridges. Matrix federation is controlled through the homeserver configuration, while Mattermost and Rocket.Chat handle external connections through their own settings. Ask the partner to document how to disable federation, test that it stays disabled after each upgrade and record the change in your audit evidence.

Questions to ask an implementation partner for an air-gapped chat build

Start with the edition. Ask the partner to name the exact product, edition and version they will deploy, and to confirm in writing that the license covers air-gapped use. The supplied facts show this is often a paid-edition feature: Mattermost lists air-gapped deployment in Enterprise Advanced, and Rocket.Chat excludes it from its free Starter plan. Ask whether the quote includes that edition's license for every environment, including test and disaster recovery enclaves, and what happens to the enclave if the subscription lapses. Then ask how push notifications reach mobile clients without a public gateway. Mobile push normally depends on a vendor-hosted relay, so the partner should explain which relay or on-premises alternative the design uses, which ports and certificates it needs, and how the mobile clients are supported on that path. Ask them to show the test result from a disconnected device, not a diagram.

Next, ask how software enters the enclave and how its integrity is checked. A strong partner will describe a written transfer procedure: packages and container images are pulled on a connected staging host, scanned, signed or hash-checked, and carried across the boundary with a record of each step. For chat, that covers the server release, the database and search images, and any plugins or bots. Ask how upgrades are rehearsed against a copy of the enclave before production. Ask about the support window too. Mattermost publishes version-specific support end dates and releases on a monthly cycle, and Rocket.Chat standard releases are supported for 6 months while LTS releases run 12 months, so the partner should state which line they will pin, when it ends, and how the enclave moves to the next line before that date. Confirm the cadence in writing rather than relying on the vendor's pages alone.

Finally, ask how federation is disabled and proven off, and how audit and retention evidence is produced inside the enclave. Federation settings should be turned off in configuration and verified with a test that attempts a connection to an external server and records the refusal. Ask for that test script and the logs it produces. For evidence, ask which audit records the chosen edition writes, where they are stored, how they are exported without leaving the enclave, and how retention periods are enforced. Use the supplied rules as the frame: SEC Rule 17a-4(b)(4) sets a three-year minimum for certain business communications, and 45 CFR 164.312(b) requires audit controls for ePHI systems. Ask the partner to map each evidence item to the control it supports, and to say which parts the assessor must verify independently.

How an air-gapped chat rollout moves from scope to operations

This sequence takes a disconnected chat deployment from a written edition decision to a running service with tested failover, a verified cutover and a repeatable monthly upgrade routine. Each phase closes with a named deliverable and a sign-off owner so the client's security and operations teams approve every boundary crossing.

Confirm scope and the edition decision
DeployOpen works with the client's security, compliance and IT leads to record the user population, guest and federation requirements, retention and legal hold duties, mobile reach, and the number of enclaves. The team checks the chosen platform's licence and edition against the air-gapped requirement, since air-gapped use is a paid-edition capability for Mattermost (Enterprise Advanced) and Rocket.Chat (paid plans, not Starter). The deliverable is a signed scope document and edition decision memo. The CISO or CIO signs off, and procurement confirms the subscription terms in writing.
Design the enclave and artifact pipeline
Architects define the enclave boundary, database and file storage design, and the controlled path by which container images, packages, rules and updates enter the isolated network. Every artifact is pulled and verified on an external staging host, then transferred through an approved media or diode process. The deliverable is an architecture record and an artifact manifest with checksums. The security architect and the boundary owner sign off, which also supports the software integrity expectations described in NERC CIP-013-2 where that standard applies.
Install offline and integrate identity
Engineers install the platform from the verified bundle with no outbound internet access, then connect single sign-on and directory sync to the client's in-enclave identity provider. Installation runs against a private registry and local package mirrors, with no call-outs to public gateways. The deliverable is a build record, a configuration baseline and a test account matrix covering each role. The identity owner and the platform lead sign off that login, logout and group mapping behave as the access policy requires.
Test push notifications and client connections
Because public push gateways are unavailable, the team tests how notifications reach mobile and desktop clients inside the restricted network, and confirms what message content those notifications carry. Mobile client compatibility is verified against the exact server version, since unsupported versions may stop connecting to official clients. The deliverable is a test report listing each device type, client version and notification path. The application owner and the security lead sign off on the results before any user onboarding.
Lock down federation and verify isolation
Engineers disable federation and any external connections, then run a negative test from inside the enclave to confirm that no outbound or cross-domain traffic is possible. Where a controlled link to another network is needed, the allow-list is documented and tested separately. The deliverable is a signed isolation test report with captured evidence. The network security owner and the compliance lead sign off, and the report is stored with the audit evidence set.
Run load and failover tests
The team tests concurrent-user load at the expected peak, then forces failure of an application node, a database member and a load balancer to observe failover behavior. For high availability on Mattermost or a multi-instance Rocket.Chat design, the test confirms shared file storage and replica behavior as the vendor documentation describes. Results are compared to the availability targets set in scope. The deliverable is a load and failover report with recorded recovery behavior. The operations lead and the business continuity owner sign off before cutover.
Cut over and migrate existing history
If prior chat history must move, the team converts and imports exported data using the platform's supported import path, then checks message counts, attachments, channel membership and retention tags against the source export. Cutover is scheduled with users, and the previous system stays read-only for a defined fallback period agreed in scope. The deliverable is a migration reconciliation report and a cutover record. The data owner and the records or legal function sign off that the migrated history is complete and retained.
Operate with a monthly upgrade runbook
After go-live, DeployOpen runs a recurring upgrade routine: it pulls the new release on the external staging host, verifies checksums, transfers the bundle into the enclave, applies it to a test copy, then promotes it to production with a documented rollback. The team tracks each vendor's support window so the platform stays on a supported line. The deliverable is a versioned runbook and a monthly change record. The platform owner and the change board sign off on every upgrade.

How DeployOpen scopes and supports air-gapped chat

DeployOpen plans, implements, hardens, documents and supports self-hosted chat platforms inside your own disconnected network. Engagements start with a written scope that fixes which edition, which transfer process and which evidence the project will deliver before any installation begins.

How we scope

Confirm in writing which chat edition licenses air-gapped use before any design work starts
Map which users, guests, channels and integrations must work on the isolated network
Define how push notifications will reach mobile clients without a public gateway, and document the limits
Agree the offline upgrade cadence against the vendor's published release and support windows

How we build

Stage container images, binaries and dependencies through a controlled import process with integrity checks
Configure SSO, directory sync and database high availability to match your identity and recovery design
Disable federation and public endpoints, then test that outbound traffic is blocked as documented
Test backup restore and a full offline upgrade in a staging enclave before production cutover

How we hand over

Deliver architecture, runbooks and the offline update procedure in documents your administrators keep
Provide configuration baselines and evidence of controls so your assessors can trace each claim
Train named administrators on user management, retention settings, export and incident steps
Transfer operation to your team or agree a retainer, as set out in the written scope

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build
Track vendor release and end-of-support dates so each offline upgrade lands inside a supported version
Re-run security testing after upgrades, configuration changes or new integrations are added
Keep documentation current so compliance preparation reflects the system as it runs