Rocket.Chat for defense and classified networks

Why Rocket.Chat for defense and classified networks needs a different plan

Rocket.Chat can fit a defense or classified messaging role only on a paid plan, and only with an offline install and update process that your team runs inside the boundary. The free Starter plan is excluded because Rocket.Chat lists air-gapped deployment as a paid-plan capability and does not offer it on Starter. Starter includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts, and those features matter, but they do not solve the deployment problem. A network with no internet path needs the platform, its database and every later update to arrive on media your team can verify. Confirm the plan entitlement in writing with Rocket.Chat before design starts, because it determines the architecture.

The build changes in several places. A standard cloud or internet-connected install pulls container images, Helm charts, packages and sometimes external services during installation and upgrades. In an isolated network, each of those becomes a transfer item: the official Docker image or Helm chart, the MongoDB package, and the dependencies they need. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, and a three-member replica set is strongly recommended for high availability. Node.js is bundled in the official Docker image and Helm chart, so you do not install it separately, but it still has to be inside your mirror. Decide early who builds the transfer bundle, who verifies it, and where it is stored before it is loaded.

Plan the update cycle as an operating function, not an occasional event. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Rocket.Chat also says unsupported versions may lose the ability to connect with its official mobile and desktop clients. Each upgrade therefore needs time for the transfer, verification, rehearsal in a staging enclave and rollback planning. Ask Rocket.Chat which cloud-dependent features are unavailable in your network and what the supported alternatives are, since a missing push gateway changes how users receive alerts.

The vendor's claims do not by themselves make a system accredited. Accreditation is a decision made by the responsible authorizing official about a specific system, as deployed, within its defined boundary, with its configuration, controls and evidence. Product documentation, feature lists and any authorization statement describe the software, not your installation. Your security plan has to show how this deployment meets the control baseline your program requires, how cryptography is implemented and which modules are used, and who is responsible for each control. Ask Rocket.Chat exactly what any impact-level authorization covers, which versions and deployment models it applies to, and which responsibilities stay with you. Then ask your authorizing official which evidence they expect.

Which defense requirements decide the Rocket.Chat build

This table lists the federal and defense requirements that most affect how a Rocket.Chat deployment is hosted, scoped and scanned, with the source of each and the build decision it drives. Read each row as a question to answer before architecture work starts, because the hosting and boundary answers change the rest of the design. The main takeaway is that where CUI is stored and who operates the platform shape more of the build than the chat features do.

Requirement	Source	What it means for the build
CUI on non-federal systems	32 CFR 2002.14(h)(2), NIST SP 800-171	Agencies set safeguards for CUI on contractor systems using NIST SP 800-171. The Rocket.Chat application, its database, file storage and backups all fall inside the protection scope you document.
Cloud hosting of CUI	32 CFR 170.17(c)(5), CMMC Level 2	A cloud service storing or processing CUI must be FedRAMP Authorized at Moderate or higher, or meet equivalent requirements. Confirm the hosting provider's status for each region before you choose cloud hosting.
Self-run installs in your own facilities	32 CFR 170.17(c)(5), CMMC Level 2	Non-cloud providers are assessed within the contractor's own scope. A Rocket.Chat install in your data center or air-gapped network is evidenced through your own boundary, not a provider's authorization.
Control baseline for evidence	NIST SP 800-53 Rev. 5 and SP 800-53B, Release 5.2.0 of 27 August 2025	Low, moderate and high baselines select 149, 287 and 370 controls and enhancements. Choose the baseline your authorization targets early, because it sets the logging, access and configuration evidence the build must produce.
Boundary definition for shared or single-agency services	FedRAMP scope under OMB M-24-15	Cloud services used only for one agency's operations, and not offered as a shared service, are out of FedRAMP scope. Decide whether the Rocket.Chat instance serves one organization or several, because that decision changes the authorization path.
Vulnerability scanning cadence	FBI CJIS Security Policy v6.1, RA-5, effective 26 June 2026	CJIS requires vulnerability scanning at least monthly. This is a comparable benchmark, not a defense rule, and it is a sound starting cadence for Rocket.Chat hosts, containers and the MongoDB tier unless your authorization sets a different one.
Encryption strength and module validation	FBI CJIS Security Policy v6.1, SC-13 and SC-28 (benchmark)	CJIS calls for FIPS 140-3 validated modules or AES with 256-bit keys for data in transit and at rest outside secure locations. Confirm which TLS, database and storage encryption paths your build uses and whether each has a validated module.
Supported release lifecycle	Rocket.Chat version durability documentation	Standard releases are supported for 6 months and LTS releases for 12 months. An end-of-life version gets no security fixes, so the upgrade path and its test window must be written into the boundary plan.

Configuration choices that matter on an isolated Rocket.Chat install

Most of the work on an isolated Rocket.Chat install is deciding a small number of configuration points early: how many instances the user count requires, how the database is built, how identity maps to roles, and how messages are retained and audited. Each choice affects what can be upgraded, recovered and proven later, so they should be settled with the security office before the build starts.

Topology sized to concurrent users

Rocket.Chat's reference architectures suggest one instance with a MongoDB replica set up to 500 concurrent users, load-balanced instances linked by NATS above 500, and Kubernetes with the official Helm chart above 5,000. Multi-instance and microservice designs require a paid plan, so the expected concurrent load and the plan must be confirmed together. Ask the vendor to confirm the current guidance for your version before fixing the topology.

MongoDB 8.0 replica set

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. On an isolated network, the database images, packages and OS dependencies must be staged in advance, and the team must plan how members are patched without taking the chat offline. Confirm the MongoDB version against the current system requirements before ordering media.

Bundled Node.js in the image

The official Docker image and Helm chart bundle Node.js, so the team does not install a separate runtime on each host. This simplifies the transfer across the boundary but means the bundled runtime is updated only when the Rocket.Chat image is. Treat each image as a versioned artifact, record its digest, and verify it against the vendor's published release before it is imported.

Directory identity and SAML group mapping

LDAP and Active Directory authentication with SAML group mapping let clearance-aligned roles follow the identity source instead of manual account edits. Clearance-based access control must be designed with the customer's security office and confirmed against Rocket.Chat's group and permission model, not assumed from the plan name. Test that a user removed from a group loses access to the relevant rooms and files.

Multi-factor authentication policy

Multi-factor authentication is available on paid plans and should be enforced by policy rather than left to individual users. Decide which factors are permitted on the isolated network, how enrollment works without internet-hosted services, and how lost devices are recovered by administrators. Verify each factor works fully offline before accepting the design.

Tamper-evident audit trails

Paid plans list tamper-evident audit trails of messages, files and sessions. These records are the evidence an assessor will ask for, so the team should confirm exactly what is logged, how integrity is protected, where logs are stored, and who can read them. Test that an administrator cannot alter a session record without leaving a trace.

Retention and deletion settings

Retention settings decide how long messages and files exist, and they interact with legal hold, records rules and the data stored in backups. Set them from the records schedule agreed with the security office rather than the default. Confirm how deletion propagates to backup copies and to files held in the storage backend.

CSV import from Slack or Mattermost

Rocket.Chat imports full Slack workspace exports, Slack users from CSV, and a generic CSV importer for other sources. Mattermost data is migrated by converting its export into CSV. Imported content can carry classification markings, unverified attachments and stale accounts into the new system, so review the source data, map users to directory identities, and test the import on a copy before production.

Which Rocket.Chat plan an isolated defense network needs

For an isolated defense network, the plan is set by the deployment model and the controls you must evidence, not by headcount. Rocket.Chat lists Starter, Community, Commercial, Government and Defense. Starter and the free Community workspace are not options for an air-gapped install, because air-gapped deployment is a paid-plan capability and is not available on Starter. Multi-instance and microservice designs also require a paid plan. The reference architectures suggest one instance with a MongoDB replica set up to 500 concurrent users, load-balanced instances above that, and Kubernetes microservices above 5,000. A network of a few hundred users that must run fully offline still needs a paid plan, so the air-gap requirement alone can settle the tier.

Before you choose, request the written feature list for the Defense plan from Rocket.Chat and map each required control against it. Use a simple table with five rows: identity, audit, retention, failover and air-gap support. For identity, confirm which directory integrations, single sign-on, multi-factor authentication and SAML group mapping the Defense tier includes, and how group mapping works with your clearance-based roles. For audit, confirm the scope of the tamper-evident trails covering messages, files and sessions, and where those logs are stored. For retention, note that retention already appears on Starter, so ask what the Defense plan adds for your retention schedule. For failover, confirm how automated failover operates on your topology. For air-gap support, ask how licenses, packages and updates are delivered without internet access.

The plan decision and its cost come from the written scope. Rocket.Chat prices its paid plans by quote, so no figure in this section replaces that quote. Ask the vendor to itemize the tier, the subscription term, the support level and which charges recur each year. Your own costs sit outside the license: hosts or virtual machines for each instance, a MongoDB 8.0 or later replica set with at least three members for high availability, storage, backups and the staff time for patching in a disconnected network. DeployOpen's fee follows from the written implementation scope, which should list the plan, the instance count and the controls to be verified. The main cost drivers are the tier, the number of instances, the redundancy you require and the number of isolated environments such as test and production.

Plan the upgrade path into the purchase, because an unsupported version in an isolated network is still a risk. Rocket.Chat supports standard releases for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes, and cloud services such as the push notification gateway stop working. Rocket.Chat also says unsupported versions may lose the ability to connect with its official mobile and desktop clients. Confirm which release line your Defense plan covers, how often you must move to a supported release, and how the vendor delivers those releases into an offline environment. Also confirm the license terms for the air-gapped copy, since the enterprise directories in the source code fall under a separate enterprise license.

Rocket.Chat for defense compliance: what the platform supports and what you must document

Each card covers one item that assessors and authorizing officials ask about for a self-hosted Rocket.Chat deployment. Read them as a list of early decisions: where the boundary sits, which obligations apply to you and which to your hosting provider, and what evidence you keep. Your assessor and authorizing official make the determination for your system.

Drawing the accreditation boundary

The authorization boundary is the set of components, interfaces and people whose security your authorizing official must accept. For a self-hosted Rocket.Chat deployment in your own facility, it usually includes the application servers, the MongoDB replica set, file storage, backups, identity integration, network paths and administrator access. Confirm with your assessor whether the virtualization or Kubernetes layer beneath the application sits inside the boundary. A vendor's authorization claim does not carry over to your boundary, so each component needs its own evidence.

CMMC cloud scoping

Under 32 CFR 170.17(c)(5), a contractor pursuing CMMC Level 2 may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. A Rocket.Chat instance you run on hardware you control stays within your own assessment scope. If you use a hosting provider, that provider is assessed under its own rules, so request its FedRAMP or equivalent evidence and map which responsibilities sit with it and which stay with you.

NIST SP 800-171 safeguards for CUI

32 CFR 2002.14(h)(2) directs federal agencies to use NIST SP 800-171 when they set requirements for protecting controlled unclassified information on non-federal information systems, unless the CUI category's authority prescribes other safeguards. A Rocket.Chat server in a contractor's facility therefore needs its access control, audit, configuration, media protection and incident response practices mapped to those requirements. Check each message store, file attachment, export and backup location, because CUI can persist in places a team overlooks.

RMF and FISMA oversight roles

Under FISMA, Inspectors General independently assess agency system security and report to OMB. Within the Risk Management Framework, the authorizing official decides whether to accept the risk of operating the system. For Rocket.Chat, the authorizing official needs a package showing how SP 800-53 Rev. 5 controls are implemented in your environment, and the Inspector General will test that package independently. Ask early which control baseline applies and who holds the obligation to obtain the authorization.

Cryptographic module expectations

Assessors ask which cryptographic modules protect data in transit and at rest, and whether those modules carry FIPS 140-3 validation. The FBI CJIS Security Policy version 6.1, effective 26 June 2026, is one example: it requires FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits for criminal justice information outside physically secure locations. Confirm which validations apply to your Rocket.Chat build, including TLS termination, MongoDB connections and the Node.js runtime bundled in the official image, and whether your program requires the same level.

Audit evidence to keep

Assessors judge a self-hosted system by its records. Keep the configuration baseline for each release, a control mapping from each safeguard to its implementation, upgrade and patch records against supported version lines, and vulnerability scan results. Rocket.Chat states that unsupported versions lose security fixes and compatibility with its official clients, so your upgrade history is itself evidence. Confirm whether the tamper-evident audit trail for messages, files and sessions is included in the plan you buy, and where those logs are forwarded and retained.

What a vendor IL6 authorization claim does and does not cover for your system

A vendor's impact-level authorization claim is evidence about one named service, at one version, in one hosting environment, as it stood when the authorization was granted. It is not a statement that every installation of the software inherits that status. A self-hosted Rocket.Chat deployment under the Defense plan is a different system from the one the vendor assessed if your hosting, MongoDB replica set, identity sources, network paths or data differ. Before your team relies on any impact-level claim for Rocket.Chat, verify that claim yourself. This page does not state which impact level, if any, Rocket.Chat holds.

Start by requesting three items from the vendor: the authorization letter itself, the boundary the authorization covers, and the date it was granted. Read the letter for the issuing body, the grant date, any expiration or review conditions, and any stated dependencies or conditions. Read the boundary description for the components inside it, such as the application tier, database, file storage, identity integration and hosting platform. Compare the named version with the one you plan to run. Rocket.Chat releases move quickly: 8.9.0 was published on October 5, 2026, and standard releases receive support for 6 months, so a letter tied to an older line may describe a version you will not deploy.

Then get written answers to specific questions. Ask whether the claim applies to self-hosted Defense plan deployments, and whether it covers air-gapped installs at all. Ask which deployment patterns sit inside the boundary: single instance, multiple instances, or Kubernetes with the official Helm chart. Ask which identity integrations were assessed, including LDAP, Active Directory and SAML, and which MongoDB versions were in scope. Ask which controls the vendor inherits to you and which remain yours. Keep the signed answers with your system security plan so the reasoning is traceable when the claim is questioned later.

Expect the accreditation authority to ask your team for its own evidence, because the vendor's claim will not carry your system. Be ready to show a system boundary that includes every component in your install, a configuration baseline tied to your exact version, and a list of inherited controls with the evidence that supports each one. Show how identity and clearance-based access are configured, how network paths into and out of the enclave are restricted, and how data is encrypted using modules that meet the FIPS 140-3 requirement your authority specifies. Also show your vulnerability scanning, your patch and update process for packages carried across the isolated boundary, your logging, and your plan for moving off versions that have reached end of life. DeployOpen can prepare these systems, controls and evidence, but independent assessors and the authorizing official make the determination.

How a Rocket.Chat for defense rollout is phased

The sequence turns a classified or air-gapped boundary into a tested, documented Rocket.Chat service with accreditation evidence the client's own authorizing official can review. Each phase closes with a check that gates the next one.

Map the boundary and classify the data
The team agrees the system boundary, the networks and enclaves Rocket.Chat will touch, and the highest classification of information that will be posted. DeployOpen runs a workshop with the client's security office, data owners and the people who will authorize the system to confirm which data categories are in scope and which controls they trigger. The step closes with a signed boundary diagram and a data classification record that the authorizing official accepts as the basis for the plan.
Decide the plan and topology for the user count
Using the confirmed user count and concurrency, the team chooses the Rocket.Chat plan and architecture. Reference architectures suggest a single instance with a MongoDB replica set for smaller populations, load-balanced instances linked by NATS for larger ones, and Kubernetes with the official Helm chart at the largest scale. Multi-instance and microservice designs need a paid plan, and air-gapped deployment is not available on the free Starter plan, so the plan decision is recorded alongside the topology. The step closes with an approved architecture document and a written plan selection that the client's procurement team can quote against.
Design identity and clearance-based groups
DeployOpen maps how users are authenticated, how directory groups become Rocket.Chat roles and rooms, and how clearance attributes control who can join which channels. The design covers LDAP or Active Directory, single sign-on, multi-factor authentication and the group mapping that paid plans support. The step closes with a reviewed access matrix that names each group, its permitted rooms and the owner who approves changes, so the client can test it before any user is loaded.
Prepare offline artifacts and transfer them
Because the target network has no internet access, the team assembles every artifact in advance: the Rocket.Chat container images, the Helm chart, MongoDB packages and the Node.js packages the deployment needs. Each item is pulled, versioned, hashed and listed in a manifest, then moved across the boundary through the client's approved transfer process. The step closes when the manifest is reconciled on the enclosed side, with hash checks on every item, and any mismatch is logged and resolved before install.
Install in a non-production enclave first
The stack is installed in a non-production enclave that mirrors the target network controls, including the replica set, identity connections and storage layout. DeployOpen tests startup, replica set health, backup jobs, restore of a sample database and the upgrade procedure using the same offline artifacts that production will use. The step closes with a build record showing each component version and a passing set of functional checks signed by the client's platform team.
Configure security and verify the audit trail
The team applies the security configuration, including encryption settings, session and password policy, retention, file handling and the audit trail features in the paid plan. Verification covers whether the configuration matches the control plan from the boundary work, whether the cryptographic modules meet the required standard for the environment, and whether messages, files and sessions are recorded in the tamper-evident audit trail. The step closes with a configuration baseline and test results that show each setting was checked against its expected value.
Migrate prior chat data through the CSV importer
If the organization has chat history in another platform, the team plans and runs the migration with Rocket.Chat's import tools. Slack workspace exports and Slack users from CSV are supported directly, and other sources use the CSV importer, with Mattermost data converted to that format first. Each batch is imported into the non-production enclave, reviewed for user mapping, room membership and attachment handling, and only then repeated in production. The step closes with a reconciliation report that compares message and user counts against the source export.
Pilot with a limited group, then hand over evidence
A small group of cleared users runs real workflows on the production system for a period set in the written scope, and their feedback drives fixes to groups, notifications and the client's operating procedures. DeployOpen then assembles the accreditation evidence package: boundary and data records, architecture, access matrix, configuration baseline, test results, transfer manifest and operating runbooks. The step closes when the client confirms receipt of the package. Independent assessors and the authorizing official make the accreditation decision, not DeployOpen.

How to keep an air-gapped Rocket.Chat patched and supported

An air-gapped Rocket.Chat deployment stays supported only if your team carries each vendor release across the isolation boundary on a fixed cycle. Rocket.Chat standard releases receive support for 6 months and LTS releases for 12 months. After a version reaches end of life, it gets no security or bug fixes, and cloud-linked services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. The vendor also says unsupported versions may lose the ability to connect with the official mobile and desktop clients. Your patch calendar therefore has to follow the vendor's support dates for the line you run, not your own convenience.

Vendor releases are published on GitHub. Rocket.Chat 8.9.0 was published on October 5, 2026, and patch releases such as 8.6.3 and 8.5.4 followed on October 16, 2026 for older supported lines. Because the isolated network cannot pull these directly, each release needs its own intake path: a verified transfer of the artifacts, a malware and package scan on the import side, a test in a staging environment that mirrors production configuration, and a written change record that names the version, the checks run and the approver. Treat a patch for an older line as a separate decision, since moving to 8.9.0 may be a larger change than the one your current line needs.

Before you build this cycle, confirm with Rocket.Chat which artifacts and update paths it supports for offline customers. Ask whether you receive container images, Helm chart packages, archives or a package feed, whether patch releases reach offline customers on the same timing as connected ones, and which upgrade paths apply from your current version. Ask how your paid plan entitlement governs access to these downloads, and which signatures or checksums accompany each artifact so your verification step has a documented reference. Record the answers in your change procedure so the process does not depend on one engineer's memory.

The upgrade from 7.x to 8.x needs its own plan. 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. Upgrade the database layer in staging first, confirm the replica set health, and check that Node.js is supplied within the official Docker image or Helm chart so you do not import a separate runtime. Schedule the cutover with a verified backup of both the database and file storage, a rollback path you have rehearsed, and a window long enough to validate sign-in, messaging and the mobile and desktop clients.

Questions buyers ask before hiring help with Rocket.Chat for defense

What drives the cost of Rocket.Chat defense implementation work?

The cost follows the written scope, and the main inputs are the plan tier, the vendor quote, and how much isolated infrastructure must be built.

Plan tier and vendor quote: air-gapped deployment is a paid-plan capability, so the Defense or Government plan price comes from Rocket.Chat before services begin.
Topology: a single instance on a MongoDB replica set is simpler than multi-instance or microservice designs, which the reference architectures tie to a paid plan.
Enclaves and identity: each enclave, clearance group and identity source adds mapping, testing and approval work.
Offline transfer, accreditation evidence and training: each adds effort in proportion to how many people and boundaries are involved.

Ask every quote to itemize these inputs separately so you can see which ones move the price.

Which Rocket.Chat defense costs are one-time and which recur?

Installation, identity and clearance-group design, the first offline transfer procedure, and accreditation evidence are generally one-time work tied to the initial authorization. Recurring costs include the plan subscription, upgrades, patch transfers across the isolation boundary, and any support retainer.

Upgrades recur because versions reach end of life and then receive no security fixes, and unsupported versions may also lose connection to the official mobile and desktop clients. Each patch cycle involves obtaining packages, verifying them and carrying them into the enclave, and that repeats for the life of the system. Ask the quote to split one-time and recurring lines, and ask what re-assessment the accrediting body may require after a major change.

How long does a Rocket.Chat defense engagement take?

No duration can be fixed in advance. The timeline is set by the written scope, the approvals the project needs, and the transfer cycle for media and packages moving into the isolated network.

Approvals usually include security office sign-off, change approval for hosting and network access, and review by identity source owners. Each transfer cycle depends on your procedures for moving media across the boundary. Accreditation follows the authorizing official's schedule. Ask for milestones tied to approvals and transfer windows, and confirm with your accrediting contact how long their review typically takes before agreeing to an end date.

What does your team need to provide for a classified Rocket.Chat install?

The work depends on your organization providing several inputs early in the project:

Security office sign-off on the architecture, boundary and access design.
Network and hosting access inside the enclave, including approved build and transfer paths.
Identity source owners for directory integration, group mapping and multi-factor authentication decisions.
A named accrediting contact who can accept the evidence and confirm the control scope.
Custodians for media and package transfers who follow your handling rules.

Delays usually come from late sign-offs or unclear ownership of these inputs, so confirm names and responsibilities in the written scope before work starts.

Can our internal team run Rocket.Chat on an air-gapped network alone?

Yes, if the team has the skills and time. The core skills are operating a MongoDB 8.0 replica set, deploying with Docker or Kubernetes, configuring directory integration, and administering Rocket.Chat.

The main ongoing task is the offline update process: obtaining releases outside the enclave, verifying their integrity, moving them through approved channels, and testing them before production. Teams often underestimate this recurring cycle. Confirm with Rocket.Chat which packages and images the Defense plan supplies for offline use, how license keys are handled, and what documentation covers updates in an isolated environment.

Does DeployOpen prepare accreditation evidence for Rocket.Chat systems?

DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent assessors and authorizing officials make those determinations.

Evidence typically includes boundary and architecture diagrams, configuration baselines, identity and access design, logging and audit settings, backup and patch procedures, and test results. The evidence set should match the control framework your accrediting contact requires. Confirm that framework, the documentation format and the review process with them before the work is scoped.

Does a vendor's IL6 authorization claim cover our Rocket.Chat deployment?

Not automatically. A vendor authorization describes the vendor's product or service within its own boundary, so it applies to your system only where your deployment matches that boundary and your authorizing official accepts it.

Get the scope in writing from Rocket.Chat. Ask which version, hosting model and components are included, and which responsibilities remain with the customer. Your system still needs its own authorization decision from your accrediting official, and that decision depends on your enclave, identity design and operating procedures, not on the vendor's claim alone.

How DeployOpen scopes and delivers Rocket.Chat for defense

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For Rocket.Chat on defense and classified networks, the plan starts from the plan tier, the isolation model and the access model before any installation work begins. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.

How we scope

Written scope confirms the Rocket.Chat plan tier, since air-gapped deployment is a paid-plan capability.
Scope records the network boundary, identity sources, and how user groups map to the access controls your authorization requires.
Vendor IL6 claims and FIPS 140-3 coverage are confirmed with the vendor and your authorizing official before design.

How we build

Isolated install packages are assembled and checked for integrity before they cross the air-gapped boundary.
Deployment design covers a MongoDB 8.0 replica set, where a three-member set is strongly recommended for high availability.
Access controls, audit trail settings and session policies are configured and tested against the scope's requirements.

How we hand over

Handover documents the installed versions, update procedure from offline media, and each configuration decision.
Verification records show which controls were tested, what passed, and what remains open for your assessor.
Runbooks cover backup and restore, package intake, user offboarding, and the upgrade steps your team runs.

How we support

Retainers cover ongoing support, upgrades and continuous testing for the deployment, agreed in writing.
Upgrade planning follows Rocket.Chat's release lines, since unsupported versions lose security fixes and mobile client support.
Each package carried across the boundary is re-verified during updates, so the update path stays documented and repeatable.