Why an air-gapped Rocket.Chat deployment needs a paid plan and a transfer process
Air-gapped Rocket.Chat is a paid-plan capability. It is not available on the free Starter plan, so a team that must keep messaging inside an isolated or classified network should treat the plan choice as the first decision, before any hardware or software is ordered. Rocket.Chat's plans are Commercial, Government and Defense, and they are priced by quote, so the plan you need depends on the written scope of your deployment. The hard parts are not the installation itself. They are moving software and updates across the gap and replacing the cloud services that a connected Rocket.Chat instance normally relies on. The deployment choices come first. Decide how many instances you need based on concurrent users, since Rocket.Chat's reference architectures suggest a single instance with a MongoDB replica set up to 500 concurrent users, load-balanced instances linked by NATS above that, and microservices on Kubernetes with the official Helm chart above 5,000. The multi-instance and microservice designs also require a paid plan. Confirm which MongoDB 8.0 or later replica set topology your environment can host, because Rocket.Chat 8.x requires a replica set and a three-member set is strongly recommended for high availability. Node.js is bundled in the official Docker image and Helm chart, which simplifies what you must transfer. The transfer process is the core operational risk. Every container image, Helm chart, package and update must be downloaded on a connected system, verified, moved through your approved media or cross-domain path, and loaded into your internal registry. Plan this as a repeatable procedure with a named owner, a checksum or signature check at each hop, and a record of what was imported. Updates follow the same path. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months, and after end of life a version gets no security fixes and cloud services stop working. You will therefore need a transfer cycle that keeps you inside a supported line. Before you commit, confirm the following with Rocket.Chat in writing: which features in your chosen plan work without internet access, how the push notification gateway and mobile clients behave in an isolated network, what offline licensing and renewal look like, and which Marketplace or Omnichannel integrations depend on cloud services. This page covers those deployment choices, the build sequence, and the checks to run. DeployOpen does not publish prices. A quote follows from written scope, so the more precisely you describe your user count, network zones, identity sources and transfer constraints, the more accurate that quote will be.
Which Rocket.Chat components must work inside the isolated network
A Rocket.Chat deployment in an isolated network depends on five components, and each one either runs inside your perimeter or relies on a service that needs outside access. Map every component before you request a quote, because the paid plan that enables air-gapped deployment and the version-specific requirements from Rocket.Chat determine what you can run offline. Confirm each item in writing for your version and plan.
Rocket.Chat server
The application server ships as an official Docker image or Helm chart, and Node.js is bundled inside both, so you do not install a separate runtime. In an isolated network, the image or chart must be transferred across the gap and loaded into your internal registry before any install or upgrade. Confirm with Rocket.Chat which image and chart versions your paid plan entitles you to mirror, and whether the server starts and runs with no outbound connections enabled.
MongoDB replica set
Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so a standalone database instance does not meet the requirement. Rocket.Chat strongly recommends three members for high availability, and every member must sit inside the isolated network with its own storage and backup path. Confirm the exact MongoDB build that your Rocket.Chat version supports, and plan how MongoDB packages and security patches will reach the network.
NATS messaging layer
NATS is the messaging layer that links load-balanced Rocket.Chat instances in multi-instance designs. Rocket.Chat's reference architectures suggest multiple instances linked by NATS above 500 concurrent users, and these designs require a paid plan. Below that scale, confirm with the vendor whether a single instance meets your needs. Where NATS is required, it must run inside the network and be included in your image transfer, patching and monitoring.
File storage
Uploaded files, avatars and attachments need a storage location that stays entirely within your network. The storage choice affects backup scope, retention settings and restore time, so settle it during design before the first production upload. Ask Rocket.Chat which file storage options are supported for your version and plan without external services. Then run a full restore test that covers both the database and the stored file contents.
Mobile push notification gateway
Mobile clients receive notifications through a push notification gateway that Rocket.Chat operates as a cloud service. From inside an air gap, that path cannot reach its endpoint, so users may miss alerts unless you approve an alternative. Ask Rocket.Chat in writing how push works for your plan, whether a self-managed gateway option exists, and how the official mobile apps behave when push is unavailable.
Which isolation model fits your network and how it changes operations
This table compares three ways to move images and updates across an air-gapped Rocket.Chat network, followed by three push notification options. Read each row against your network policy, your update obligations and the evidence your assessor expects. The main takeaway is that the connectivity model sets your update cadence and evidence trail, so choose it before sizing the team.
| Option | When it fits | Operational effort | Effect on updates and evidence |
|---|---|---|---|
| Fully isolated, manual transfer | Small teams with infrequent updates and a strict media control process in a segment with no path to outside networks. | High. Each image, patch and deployment bundle is staged, checked and carried across by hand under a written checklist. | Slowest cadence. Each transfer can leave hash and approval records for assessors, but falling behind supported releases is easy. |
| Isolated with one-way controlled import | Regulated networks that need regular updates and can host an import point with logging and malware scanning. | Medium to high. A scanning and approval pipeline, a staging registry and a repeatable import runbook must be built and maintained. | Predictable cadence tied to a release calendar. Import logs, scan results and signed artifacts give assessors clear evidence. |
| Restricted egress to approved sources | Networks that allow outbound traffic only to named internal mirrors, registries and update sources through a proxy. | Medium. Firewall rules, an internal registry mirror and allowlist reviews must be kept current as sources and versions change. | Fastest cadence within approved sources. Egress logs and allowlist change records form the evidence trail, so confirm the format with your assessor. |
| Push: no push | Teams that accept in-app notifications only, with desktop and mobile users checking the client manually. | Lowest. Nothing extra to run, but mobile users lose background alerts and staff need clear expectations. | No external dependency to version. Record the alert gap in the risk register so the decision is accepted in writing. |
| Push: supported internal path | Only where your plan and Rocket.Chat version confirm an internal push route. Ask the vendor before design. | Depends on the confirmed design. Confirm components, hosting and maintenance owners before estimating effort. | The push path must match the server release. Cloud push services stop after end of life, so supported versions matter. |
| Push: controlled relay | Where mobile alerts are required and an approved relay you host can be reviewed, monitored and patched. | Medium. A relay service, certificate handling and device token management, plus monitoring, must be built and maintained. | Relay versions must track server releases. Retain relay logs as evidence of what left the network and why. |
How to build an air-gapped Rocket.Chat deployment in order
This sequence takes a team from plan confirmation to a verified, internally reachable Rocket.Chat instance with authenticated MongoDB, internal identity and TLS, and a controlled first login. Each step closes with a check that the next step depends on.
Confirm the paid plan and target version
The account owner confirms with Rocket.Chat, in writing, that the paid plan covers an air-gapped deployment, since this capability is not available on the free Starter plan. Then select the target release from a supported line. Standard releases are supported for 6 months and LTS releases for 12 months, and an end-of-life version stops receiving security fixes and loses cloud-dependent services. Done when the written plan confirmation and the chosen version are filed with the change record.
Inventory every image, chart and package
The build team lists every artifact the target release needs: the Rocket.Chat container image or Helm chart, the MongoDB 8.0 or later server and tool packages, the reverse proxy, operating system packages, and any Marketplace apps. Node.js ships inside the official Docker image and Helm chart, so confirm whether a separate runtime is needed at all. Each item gets a version, a source location and a named owner. Done when someone outside the build team has reviewed the list and every line has all three fields filled in.
Stage artifacts on an approved medium
The team copies the inventoried artifacts onto the transfer medium your security policy approves for this data classification. Keep the staged set in the same folder structure as the inventory so the receiving team can match each file one to one. Add nothing that is not on the list. Done when the staging manifest matches the bill of materials line by line and the transfer is logged in the transfer register.
Verify checksums on both sides
On the source side, the team generates a checksum for each artifact and records the values in the manifest. After the medium enters the isolated network, the receiving team recomputes every checksum and compares the results. A mismatch stops the process: quarantine the file, re-stage it from source and repeat the comparison. Confirm with the vendor whether signed artifacts are available and verify those signatures as well. Done when every file matches its recorded value and the comparison output is stored with the change record.
Stand up an authenticated MongoDB replica set
The database team deploys MongoDB 8.0 or later as a replica set, since Rocket.Chat 8.x requires a replica set and a three-member set is strongly recommended for high availability. Enable authentication with internal cluster authentication, then create a dedicated application user with only the privileges Rocket.Chat needs. Bind each member to internal addresses only. Done when the set reports one primary with all members healthy, and an unauthenticated connection attempt is refused.
Install Rocket.Chat against internal endpoints
The platform team installs Rocket.Chat with the MongoDB connection string pointing to the internal replica set members and the site URL set to an internal hostname. Block outbound routes for updates, telemetry and external push gateways at the network layer so any attempt fails visibly. Expect cloud-dependent features, including the push notification gateway, to be unavailable in this design, and document that for users. Done when the service starts, the health check reports healthy, and a network capture shows no connections to external addresses.
Configure identity and TLS internally
The identity team connects Rocket.Chat to LDAP or Active Directory and, where your plan includes it, to SAML or OAuth single sign-on, using directory services inside the network. Issue TLS certificates from your internal certificate authority and trust that authority on the Rocket.Chat host and the reverse proxy. Enable multi-factor authentication if policy requires it. Confirm with Rocket.Chat which identity methods your plan includes. Done when a directory test bind succeeds, the certificate chain validates from a client inside the network, and the administrator signs in through the configured method.
Run a controlled first login
The team starts with a small group of named test accounts, including one administrator, and has them sign in only through the approved client paths. Testers check that messages send, that history survives a service restart, that uploads land on the configured storage, and that notifications work without internet access. Log every issue in the change record and resolve it before widening access. Done when the test group completes the checklist, the restart test passes, and the service owner approves opening access to the wider group.
How to get images, charts and updates across the air gap safely
The safest way to bring Rocket.Chat images, charts, MongoDB packages and patches into an isolated network is a repeatable workflow with four steps: build a manifest on the connected side, move the artifacts through your approved cross-domain process, load them into an internal registry or repository, and record what was imported and when. The manifest is the control point. It lists every artifact by name, version and digest, so that the team inside the enclosed network can confirm that what arrived is exactly what was approved. Without it, a later question such as which patch level is running in production becomes a search through transfer folders rather than a lookup.
Treat each component as its own line item. The Rocket.Chat server image and Helm chart are one group. The MongoDB packages are another, and Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so the manifest should name the exact MongoDB build and confirm it matches the Rocket.Chat release notes you are deploying. Release notes are a transfer item too. Copy them across with the artifacts, because the operators who approve a later upgrade will need the documented changes, known issues and upgrade steps to be available inside the network. Patch releases, such as those published on the Rocket.Chat GitHub releases page, follow the same path, but each patch needs its own manifest entry and its own approval record.
Before any transfer, confirm which artifacts are actually available offline for your version. Some items you depend on may be pulled at runtime from external services, and the paid-plan features you buy may rely on cloud services that do not exist inside an enclosed network. Ask Rocket.Chat and your deployment team to list every external dependency for the specific version and plan you license, and mark each one as bundled, mirrorable or unavailable. Also confirm that your support window covers the release you are moving. Standard releases are supported for 6 months and LTS releases for 12 months, so a patch that arrives after your transfer cycle may already be the only fix worth carrying across.
The transfer approval belongs to your security team. They decide which cross-domain route is used, what scanning or inspection each artifact must pass, who signs off on each batch, and how long the approval record is retained. DeployOpen prepares the process around those decisions: the manifest template, the import runbook for the internal registry or repository, the checks that compare digests after loading, and the evidence pack that shows what was imported and when. DeployOpen does not approve transfers and does not produce audit or certification evidence. Those outputs feed your own assessors and, where relevant, independent auditors.
Finally, agree on a cadence before the first transfer. Decide who builds the manifest, who reviews it, who performs the import, and who records the outcome. Set a rule for emergency patches so that a security fix can move through the same controls on a shorter path without skipping the digest check. Illustrative example: a team that transfers a monthly batch, plus an out-of-cycle batch for a critical fix, can keep one manifest format and one approval record for both. The discipline matters more than the speed, because an unverified image in an isolated network is hard to detect later.
How to secure the isolated Rocket.Chat stack
The air-gapped build removes the internet-facing defaults that many hardening guides assume, so each control has to be set deliberately inside your own network. The six controls below cover network paths, certificate trust, secrets, administrator access, data handling and the app catalog. Each card names the evidence assessors are likely to request, but your internal auditors or independent assessors decide whether the result meets your requirements.
Default-deny network rules
Treat the Rocket.Chat application servers, the MongoDB replica set and the file storage backend as separate zones. Allow only the flows each one needs: clients to the reverse proxy, application servers to the MongoDB replica set ports, and application servers to the file store. Block all other traffic in both directions, including outbound connections, because an isolated network still needs east-west controls. Evidence to request: exported firewall or security group rules, a flow matrix, and test logs showing denied connections.
Internal CA trust for TLS
Issue certificates for the reverse proxy, the Rocket.Chat endpoint and MongoDB from your internal certificate authority, then install the root certificate in every host and container trust store that calls them. Confirm that the Node.js runtime bundled in the official image trusts the same chain, since a mismatch usually appears as connection failures that teams often work around by disabling verification. Evidence to request: the CA policy, a certificate inventory with expiry dates, and the renewal runbook.
MongoDB authentication and replica set keys
Enable MongoDB authentication with a dedicated database user for Rocket.Chat and separate credentials for database administrators. Generate the replica set keyfile and database passwords per environment, and store them in a secrets manager or in files injected at runtime, never in compose files, Helm values committed to Git or container images. Document the rotation schedule and test it. Evidence to request: a secrets inventory without the values, access logs for the secrets store, and a repository scan report showing no stored credentials.
Administrator accounts and MFA
Create named administrator accounts through your directory and keep only one sealed break-glass local account, with its use logged and reviewed. Enforce multi-factor authentication through the identity source you connect. The plans page lists MFA as a feature, so confirm that it applies to the paid tier your air-gapped build requires. Map administrator roles from directory groups so that removing someone from the group also removes workspace admin rights. Evidence to request: a role assignment export, the MFA enforcement configuration, and a deprovisioning test record.
Retention and end-to-end encryption settings
Set message and file retention policies to match your records schedule, and decide which channels, if any, use end-to-end encryption. These settings interact: encrypted content is not readable by the server, so retention and eDiscovery workflows need a documented position for those channels. Confirm the defaults in the admin console and record them in configuration management. Evidence to request: the retention policy export, a list of channel-level encryption decisions, and the exception process for legal holds.
Restricted app installation
Without Marketplace access, every app must come from a package your team has reviewed and staged inside the network. Restrict app installation to a named administrator group, limit the permissions each app requests, and keep a register of approved apps with versions and owners. Test each app against the Rocket.Chat release you plan to run, because compatibility changes with upgrades. Evidence to request: the approved app register, the installation audit log, and permission review records.
How push notifications and mobile clients behave without internet access
The push notification gateway is a cloud service, so an air-gapped Rocket.Chat deployment cannot rely on it to alert mobile users. Rocket.Chat's version durability documentation states that after a version reaches end of life, cloud services such as the push notification gateway stop working. The same documentation warns that unsupported versions may also lose the ability to connect with the official mobile and desktop clients. Before the rollout is approved, the team should confirm with Rocket.Chat whether an internal push path exists for the plan and version they intend to run, and whether that path needs any extra license, component or network rule. Do not assume that a gateway which works in a connected lab will work behind the air gap.
Without a working push path, users see a predictable pattern. Messages still reach the server and the desktop and web clients, but a phone only shows new messages when the app is open or recently active. Mentions, direct messages and calls can be delayed until the user returns to the app. Set this expectation in writing before go-live, for example in the onboarding guide and the internal announcement, and tell security and operations leads that on-call and urgent escalations should not depend on mobile alerts. Where the business needs timely alerts, plan a fallback such as a desk phone, a radio channel or a second system that is already in the approved environment.
Mobile clients also need a clear version and network baseline. Confirm with Rocket.Chat which mobile client releases are supported against your server version, and pin that combination in your device management policy. Old app builds can fail to connect after a server upgrade, so the app catalog on managed devices should only offer approved versions. On the network side, the phone must reach the internal Rocket.Chat hostname over the HTTPS port your reverse proxy exposes, and the certificate chain must be trusted by the device. Work with the mobile device management team to confirm that the internal certificate authority is installed on managed profiles and that the app is not blocked by a network or application allowlist.
Test these conditions on real managed devices before rollout, not only on an emulator. Use a device on the corporate Wi-Fi or a segment that mirrors production, and confirm that login, channel loading, file download and message sync work with the public internet blocked at the perimeter. Then send a test message from a desktop client, lock the phone and check what arrives and when. Repeat the test after the next server upgrade, because version drift is the most common cause of mobile breakage. Record the results, the device models, the app build and the server version, so the evidence can be reused in change reviews and compliance reviews.
Ask the implementation partner and Rocket.Chat for a written answer to four questions: whether an internal push option is available for your plan and version, what it requires in infrastructure, which mobile client builds are supported, and what the support window is for the server version you plan to run. Those answers determine whether mobile alerting is a fixed feature or a documented limitation that the business accepts. Treat any unsupported assumption as an open risk in the project plan, and review it at each upgrade cycle.
What drives the effort and cost of an air-gapped rollout
This table lists the main drivers of effort and cost in an air-gapped Rocket.Chat rollout, why each one changes the work, and how to keep it contained. Use the last column to separate project work from costs that continue after go-live. Prices come only from a written quote, so use these rows to build the scope you send to vendors and partners.
| Driver | Why it changes effort or cost | How to keep it down | One-time or recurring |
|---|---|---|---|
| Concurrent users | Reference tiers set the topology: one instance up to 500 concurrent users, load-balanced above 500, Kubernetes microservices above 5,000. Multi-instance and microservice designs need a paid plan. | Size from measured peak concurrency, not total headcount, and avoid a higher tier than your load needs. | One-time design, recurring capacity review as usage grows |
| Isolated environments | Each enclave, staging or disaster recovery site repeats installation, certificates, identity setup and backups. | Use one reviewed build pipeline and promote identical artifacts between environments. | One-time per environment, recurring patching in each |
| Transfer approval steps | Every image, update and app crossing the gap goes through review, approval and media handling. | Batch updates into scheduled transfer windows and agree the evidence package before the first transfer. | Recurring with every release cycle |
| Customization and app vetting | Marketplace apps, private apps, webhooks and bots each need a security review before they enter the network. | Limit the app list to approved apps and standardize private app templates and permissions. | One-time vetting, recurring re-review at each upgrade |
| Identity integration | LDAP or Active Directory sync, SAML or OAuth single sign-on and group mapping depend on identity services that must reach the isolated network. | Confirm which identity sources are reachable from the enclave before design starts. | One-time build, recurring user and group lifecycle work |
| Mobile device management | Mobile clients and push notifications depend on device policy and on how notifications work without internet access. Confirm this path with Rocket.Chat for your plan and version. | Decide early whether mobile access is in scope and document the notification path for assessors. | One-time design, recurring device policy and client updates |
| Upgrade cadence | Standard releases get 6 months of support and LTS releases 12 months, per Rocket.Chat's version durability docs. Expired versions lose fixes and mobile connectivity. | Plan releases on the LTS line where possible and schedule each transfer around the support window. | Recurring for every upgrade cycle |
| Compliance evidence requests | Assessors ask for version records, access reviews, backup restore tests and audit trail exports that must be produced from the isolated environment. | Map each request to a named artifact early and collect it during normal operations. | One-time mapping, recurring collection each assessment cycle |
How to test that the isolated deployment works and fails safely
The verification plan should prove two things before any user signs in: the platform works inside the isolated network, and it fails closed when something is missing or expired. Start with the network. From the Rocket.Chat application host and the MongoDB hosts, confirm there is no default route to the internet and that a direct outbound connection to an external address fails. Then make a deliberate outbound call from a test host in the same segment, such as an HTTPS request to a public endpoint. Confirm the call is blocked at the firewall or egress proxy and that the attempt appears in the logs with a timestamp and source address. If the attempt does not appear in the logs, the control is unproven, and your security operations team will have no record to work from.
Next, test the functions users depend on. Confirm that DNS and any proxy settings resolve only internal names, so the server, the mail relay and the identity source are reached through internal records. Sign in through the internal identity source, LDAP or Active Directory, or your SAML identity provider if you use one, and complete MFA with a test account. Then send and receive messages between two desktop or web clients, covering both a direct message and a channel. Upload a file from each side and check that it is stored in the configured location, that it downloads correctly, and that the retention setting removes it after the period you configured. Record the retention period and the test time so the result can be repeated after each change.
Mobile clients need their own test. Connect the official mobile app to the internal address with a test account, confirm sign-in and message sync, and then observe behavior with push unavailable. The push notification gateway is a cloud service that an isolated network cannot reach, so users should expect messages to arrive only while the app is open, and notifications may be delayed or absent. Confirm this against the documentation for the exact version you run, and decide with the business whether that trade-off is acceptable or whether another notification path is needed. Finally, restore a MongoDB backup into a separate environment with the same replica set layout, start Rocket.Chat against it, and confirm that users, channels and recent messages match the source.
Then test the failure paths deliberately. For a missing image, remove or rename a required image in your offline registry, attempt a deployment, and confirm the failure is explicit and the running version stays unchanged. The deployment should not pull from any other source. For an expired certificate, install a certificate with a short test validity period on the reverse proxy, then confirm that browsers and mobile clients reject it and that your monitoring raises an alert before expiry, not only after users report errors. For a version outside the support window, compare the running version with the release list and the version durability policy. Standard releases are supported for 6 months and LTS releases for 12 months. After end of life, the push gateway, Marketplace and Omnichannel integrations stop working, and mobile connectivity may break. Record each result as pass or fail, with the evidence and the named owner for any remediation.
What buyers ask before bringing in help for an air-gapped Rocket.Chat rollout
Does an air-gapped Rocket.Chat deployment require a paid plan?
Yes. Air-gapped deployment is a paid-plan capability and is not available on the free Starter plan. Starter allows up to 50 users and includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts, but it does not cover an isolated network. Rocket.Chat's paid plans are Commercial, Government and Defense, and they are priced by quote. Choose the tier with Rocket.Chat against your user count, your sovereignty or accreditation requirements, and the features you need, such as SAML user group mapping, tamper-evident audit trails and automated failover. Ask Rocket.Chat to confirm in writing which tier covers your air-gapped terms before you design the environment.
What does an air-gapped rollout cost, and what drives the price?
The cost has several parts, and each is paid to a different party. Rocket.Chat is paid for the subscription under the plan you select, which is quoted separately. Your organization pays for the infrastructure inside its own network, including compute, storage, backup and the MongoDB 8.0 replica set that Rocket.Chat 8.x requires. Implementation labor covers planning, installation, identity integration, the transfer process, testing and documentation. Most of these items are one-time, while the subscription, infrastructure, upgrades and support recur. The main drivers are user count, the number of instances, the identity sources to connect, the volume of data to import, and how many approval steps your transfer process needs. Ask any quote to split these items so you can compare them with an internal build.
How long does an air-gapped Rocket.Chat deployment take?
Duration depends on the factors that set the scope, not on a fixed number. Rocket.Chat's reference architectures suggest one instance with a MongoDB replica set for up to 500 concurrent users, multiple load-balanced instances linked by NATS above 500, and microservices on Kubernetes with the official Helm chart above 5,000. Each step up adds design, testing and operating work. Other drivers include how quickly your teams approve media transfers across the gap, how complete your network diagrams and identity data are at the start, how many devices need mobile client testing, and how much history you migrate from Slack or another tool. Ask for a timeline built from a written scope with named milestones and dependencies, and ask which of those dependencies sit with your teams.
What must our team provide before an air-gapped engagement starts?
Plan to provide the items that the design depends on. Start with network diagrams that show the isolated segments, the boundary controls and the paths for moving software packages and container images. Provide your identity source details, including the Active Directory or LDAP directory, any SAML identity provider, and the group structure used for role mapping. Document the transfer approvals required for each move across the gap, including who signs off and how media is handled. Supply a device list covering the phones, tablets and desktops that will run the official clients, with their operating system versions. Also confirm your container platform, storage class, MongoDB hosting, TLS certificate authority, DNS names and backup targets. Missing items usually extend the schedule, so collect them before scoping.
Can our internal team deploy Rocket.Chat in an air-gapped network alone?
An internal team can do the work alone if it has the skills and time to carry it through. The team needs experience running MongoDB as a replica set with authentication, operating Docker or Kubernetes, managing TLS and reverse proxies, and connecting directory services. It also needs a controlled process for moving images and packages across the gap and for testing each release before it reaches production. Consider who will be on call, how change control works, and whether anyone can review the security configuration. Many organizations split the work, keeping design decisions and operations in-house while bringing in a partner for the isolated build, hardening or the first upgrade cycle. DeployOpen plans and implements these projects under a written, fixed scope, and ongoing support is available as a retainer.
How are Rocket.Chat updates delivered after go-live in an isolated network?
Updates become a recurring transfer cycle after go-live. Rocket.Chat standard releases receive support for 6 months and LTS releases for 12 months. For example, Rocket.Chat 8.9.0 was published on GitHub on October 5, 2026. After end of life, a version receives 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 the official mobile and desktop clients. Each cycle should include reviewing release notes, staging the images and packages, testing apps and integrations, planning MongoDB version upgrades, and rehearsing rollback. Confirm with Rocket.Chat how the cloud-dependent features behave in your network before you commit to a design.
Does DeployOpen provide a compliance certification for an air-gapped Rocket.Chat system?
No. DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence so your organization can take them into a compliance assessment, and independent auditors or certification bodies make the determination. For an air-gapped Rocket.Chat deployment, that preparation can include documenting the network boundaries, access controls, identity configuration, audit trail settings, retention and encryption choices, backup procedures and the update process. Ask your auditor which control evidence they expect before the build starts, because it is far easier to capture during deployment than to reconstruct afterward. Confirm the framework and scope with the assessor in writing.
What to monitor, back up, upgrade and document after go-live
After go-live, the most important operating decision is which Rocket.Chat version the isolated network runs and how it moves to the next one. Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. After end of life, a version receives no security or bug fixes, and Rocket.Chat says it may also lose the ability to connect with the official mobile and desktop clients. Cloud services such as the push notification gateway stop working too. In an air-gapped network, a version that falls out of support is not just a patching gap, it is a client compatibility problem for every user. Record the installed version, its support end date from the version durability documentation, and the date of the next planned upgrade in the operations runbook, and review that record on a fixed schedule.
Treat each upgrade as a transfer event with its own test run. The new release images, Helm charts or packages, and any MongoDB version change must cross the gap through the same approved media path used for the original install, and be verified against their published checksums before they enter the network. Stage the upgrade in a non-production copy that uses the same MongoDB replica set topology, then test sign-in through your identity provider, file uploads, message search, custom apps and integrations, and at least one mobile client on the version you expect users to run. Confirm the MongoDB compatibility requirement for the target Rocket.Chat release before you schedule the change, because a database upgrade often has to happen first.
Monitoring has to work without outbound log shipping. Watch the MongoDB replica set for member state, replication lag, and whether a primary election has occurred, since a degraded set affects message delivery even when the Rocket.Chat process looks healthy. Collect Rocket.Chat and reverse proxy logs into a store inside the network, set alerts for repeated authentication failures, certificate errors and disk pressure on the file storage volume, and confirm that the alerting path does not depend on any external endpoint. Ask your team to document where each log lives and how long it is kept, since retention settings in the isolated network are your responsibility and not a vendor service.
Back up MongoDB and file storage to media that stays inside the network, and schedule restore tests as seriously as the backups themselves. The database holds messages, users, channels and settings, while uploaded files live in the storage backend you configured, so both must be captured at a consistent point in time or the restored instance will reference missing files. Agree on backup frequency, retention and the location of the offline copy with your data owners. Then run a restore into an isolated test environment at a scheduled interval, measure how long it took, and confirm that a user can sign in, read history and open an attachment. A backup that has never been restored is an assumption, not a recovery plan.
Keep a runbook that a new administrator can follow without the original implementers. It should cover the transfer procedure for images, packages and updates, including who approves media and how checksums are recorded; the certificate inventory, expiry dates and renewal steps for the reverse proxy and any internal certificate authority; and the minimum mobile client version each Rocket.Chat release supports, so that a server upgrade does not strand users on older apps. Confirm the mobile version requirements with Rocket.Chat for your target release, since they change between releases. Store the runbook inside the network, version it with each change, and review it after every upgrade cycle.
How DeployOpen scopes, builds and hands over an air-gapped Rocket.Chat deployment
DeployOpen scopes each air-gapped Rocket.Chat deployment in writing before work starts, beginning with confirmation that a paid plan covers air-gapped operation. We build the platform inside your isolated network, then document the update path, MongoDB replica set and client connectivity so your team can operate it. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- Written scope covering the plan tier, user count and whether the deployment is single-instance or multi-instance.
- Confirmation that a paid Commercial, Government or Defense plan covers air-gapped operation before any build starts.
- Inventory of the isolated network: MongoDB hosts, file storage, identity sources, and the route for image and update transfers.
How we build
- Rocket.Chat container images and Helm charts staged through your approved transfer process into the isolated network.
- MongoDB 8.0 or later deployed as a replica set, with three members recommended for high availability.
- Mobile client connectivity documented and tested against the design, with the push route confirmed in writing before go-live.
How we hand over
- Architecture, network flow, and configuration documentation written for your operations and security teams.
- Runbooks for the transfer process, backup and restore, and the upgrade steps for each supported release line.
- Test records and configuration evidence prepared for your assessors, who decide what satisfies their review.
How we support
- Upgrade planning against Rocket.Chat's 6-month standard and 12-month LTS support windows, so versions stay supported.
- Tracking of patch releases and testing of each update in a staging copy before it reaches the isolated network.
- Retainer option for ongoing upgrades, patching and testing, with terms set out in the written agreement.
