Air-gapped Video Conferencing
You set up air gapped video conferencing by running media servers inside an isolated network. All audio, video, and sign-in services must run without any internet path. Teams often deploy self-hosted chat apps and grant broad admin roles to fix bugs fast. Overly broad roles let one bad command break the whole media server or leak data. How air gapped video conferencing works on a closed network A closed network blocks all traffic to and from the public web. Your team must host every part of t
Video-Based Session Recording: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up air gapped video conferencing by running media servers inside an isolated network. All audio, video, and sign-in services must run without any internet path. Teams often deploy self-hosted chat apps and grant broad admin roles to fix bugs fast. Overly broad roles let one bad command break the whole media server or leak data.
How air gapped video conferencing works on a closed network
A closed network blocks all traffic to and from the public web. Your team must host every part of the call stack on local servers. This stack includes a web app, a signaling service, and a media routing node. Users connect from local workstations over a private local area network.
Because public stun and turn servers are out of reach, local media nodes route packets. You also need an internal certificate authority to issue TLS keys for browser media rules. Modern browsers block camera and mic use on pages that lack valid TLS keys. Your local DNS server then points call links to the internal IP address.
User sign-in runs through a local directory service like LDAP or an internal identity provider. Admins assign host roles, guest roles, and server admin roles in this directory. Host roles let users start rooms, mute peers, and share screens during a meeting. Server admin roles let engineers log in to the underlying Linux hosts and databases.
Managing server roles and local package updates
Keeping an isolated call system running takes steady work from your operations team. Engineers must bring software patches in on physical media or through a one-way transfer node. They verify file hashes against a trusted key before they load new container images. Then they log in to the media hosts to restart services and check logs.
To make patch days fast, teams often share one root SSH key across the group. They also share a single database admin role to clean up stale room records. These shared credentials sit on admin laptops inside the closed room. Anyone with that key can run any command on the media hosts.
Video-Based Session Recording: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native network isolation solves and where it falls short
An air gap stops external attackers from reaching your video rooms over the internet. It ensures that video streams and chat messages stay inside your physical building. Native role settings in the video app also control who can join or host meetings. For many strict compliance programs, physical isolation is a mandatory base rule.
Still, physical isolation does not govern what engineers do once they log in to servers. Native OS and database roles decide who gets a session, not what commands run. An admin checking a slow call log has the same power to drop database tables. Also, if a database query returns user emails or phone numbers, raw data appears on screen. Masking tools that rewrite matched fields in results help reduce this exposure during live checks. Teams need fine-grained controls at the command level, not just at the network border.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do browsers block cameras on an internal video server?
Browsers require a secure HTTPS link before they allow camera or microphone use. You must install a root certificate from your local certificate authority on every client machine.
Can we run group video calls without a media server?
Peer-to-peer calls work for two or three people on a fast local network. Larger rooms need a local media server to mix or forward video streams without lag.
How do we audit admin actions on isolated media hosts?
Native setups rely on local system logs that admins with root roles can alter. Sending logs to a separate write-only log host keeps a clean record of server commands.