Guides

Air-gapped instant messaging: selection and deployment

The “air-gapped IM” requirement comes from a specific but well-defined set of organizations: classified units, tightly regulated finance and healthcare networks, and government environments with strict data-sovereignty rules. No internet-dependent SaaS communicator qualifies, and even self-hostable products must be checked one by one for “what does it actually contact after installation”. This guide turns offline deployment into a verifiable checklist and shows how IMCore lands in isolated networks.

What air-gapped means, and who really needs it

Air-gapped means no routed path between the deployment and the internet: software enters via removable media, updates arrive as offline packages, and monitoring and logs close the loop inside the network. True isolation is far stricter than “private cloud” — a private cloud still runs on someone else's infrastructure, while in an isolated network every layer (database, message queue, object storage, monitoring) must live inside. Overseas vendors serving defense and critical infrastructure have turned this into a mature market, proving the demand is real, well-funded, and evaluated in a standardized vocabulary: no phone-home, auditable, upgradable offline.

An eight-point offline checklist

For every candidate, demand evidence per item rather than verbal assurances:

  • No phone-home: enumerate every outbound connection attempt (license checks, update probes, crash reports, fonts and CDNs) and confirm each can be disabled
  • Offline install: installation media that never touches public registries (tarballs / private image repositories)
  • Bundled dependencies: database, cache, message queue and object storage deployable in-network, no cloud-service dependency
  • Local licensing: licenses validate locally, without a vendor activation server
  • Local identity: auth integrates with in-network LDAP / OIDC rather than public SSO
  • Monitoring loop: metrics and health checks feed in-network Prometheus-class systems
  • Offline upgrades: a formal offline package and rollback path for version upgrades
  • Client reality: mobile push depends on vendor channels, so isolated networks lean on web / desktop clients — plan agent and user access accordingly

How IMCore lands in an isolated network

IMCore's deployment units are friendly to offline scenarios: a single Go binary with no runtime downloads; Compose and Helm layouts where PostgreSQL, Redis, RabbitMQ and MinIO ship as bundled dependencies whose images can be pre-loaded into an in-network registry; licensing via locally verified signed files with no online activation; no server-side telemetry. Operations provide systemd unit generation and health probes, with metrics exposed on a standard Prometheus interface for in-network monitoring.

For acceptance in an isolated environment, work the checklist literally: capture egress traffic after installation to confirm zero outbound connections, rehearse the offline upgrade package and its rollback in a mirrored environment, then distribute the agent workbench and web clients to users.

FAQ

Can mobile clients work in an air-gapped environment?

Clients can connect to the in-network server, but offline push depends on Apple / Android vendor channels, which are unavailable in a fully isolated network — the standard practice is therefore web and desktop clients as the primary access, with mobile used where a gateway is reachable.

How do version upgrades work without internet?

Via offline packages: release artifacts are SKU-shaped tarballs and container images that can be ferried into the in-network registry on media before upgrading; validate in a mirrored environment first — database migrations have a dedicated runner with baseline mode for existing databases.

Does licensing require online activation?

No. Commercial licenses are signed files verified locally against a build-time embedded public key — the check never contacts a vendor server.

Keep reading

Head-to-head comparisons

/en/compare/ →

Production deployment with Docker Compose

/en/docs/deploy-docker-compose/ →

Self-hosting a chat server

/en/docs/self-hosted-chat-server/ →

Self-hosted customer service software: why and how to choose

/en/topics/self-hosted-customer-service/ →

Self-hosted live chat: a practical guide

/en/topics/self-hosted-live-chat/ →

Self-hosted AI customer service: an on-prem selection guide

/en/topics/self-hosted-ai-customer-service/ →

READY TO OWN THE CONVERSATION?

Bring your workload. We’ll size the architecture.

Share your concurrent connections, daily message volume and deployment environment for a concrete edition and topology recommendation.

We usually reply within one business day