Airgapped Delivery
You set up airgapped delivery by bundling app code and images into a signed file. Then you move that bundle across a physical gap to your offline servers. Teams often use portable drives or one-way data links to move these files. Once the bundle lands inside the network, operators unpack it to a local registry. From there, internal tools deploy the app to local servers and databases. Still, teams often grant broad admin roles to make offline updates work fast. Those wide permissions create major
Delivery: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up airgapped delivery by bundling app code and images into a signed file. Then you move that bundle across a physical gap to your offline servers. Teams often use portable drives or one-way data links to move these files. Once the bundle lands inside the network, operators unpack it to a local registry. From there, internal tools deploy the app to local servers and databases. Still, teams often grant broad admin roles to make offline updates work fast. Those wide permissions create major risks once someone logs in to the isolated network.
How to build an airgapped delivery workflow
A strong airgapped delivery pipeline starts on your connected build servers. First, your build tool compiles the app code and gathers every required package. You must include container images, OS packages, and database change scripts in one bundle. Next, the build system hashes the bundle and signs it with a private key. This signature proves that nobody changed the files during transit.
After signing the bundle, an operator moves it across the physical gap. Some teams copy the bundle onto an encrypted hardware drive and walk it over. Other teams send the file across a one-way optical link that blocks return traffic. Inside the isolated room, a receiving host checks the signature with a public key. If the signature matches, the host unpacks the images into a local registry. Finally, local deployment tools pull from that registry and update the running apps.
What native network isolation solves and where it falls short
Physical isolation stops external attackers from reaching your servers over the public internet. It also stops internal apps from calling out to untrusted external hosts. Your signed bundle setup ensures that only approved code enters the offline room. Network walls and file checks decide which packages and users can enter the room.
Still, physical walls do not control what happens after an operator logs in. Offline apps still fail, and engineers must log in to fix broken database updates. Because offline debugging is hard, teams often share static admin keys and broad roles. Native network isolation decides who gets inside the room, not what individual commands do. Once an operator opens a database session, the network cannot check individual queries. A tired engineer can still run a bad update that drops a table. In the same way, a query can return raw card numbers or national IDs. Without controls on active sessions, your offline data remains exposed to human error.
Delivery: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing operator roles during offline updates
To reduce risk during offline updates, teams must tighten local role permissions. Start by splitting deployment roles from day-to-day debugging roles on your local servers. The automated deployment tool should use a dedicated role that only runs migration scripts. Human operators should log in with separate accounts that default to read-only permissions.
Even with read-only roles, sensitive fields in local tables need extra care. Standard database roles grant table reads as an all-or-nothing choice. If an engineer queries a user table to check a bug, every column appears by default. You also need a clear audit log of every command run during an update. Native server logs often scatter across many machines inside the offline network. Collecting and reviewing query logs by hand takes hours after every release. Teams need a way to inspect commands in flight and mask fields like emails.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How do you handle missing dependencies during an offline update?
You must test the full bundle in a staging room with no internet first. That test run reveals any hidden external calls or missing packages before release day.
How do you verify that an offline bundle was not altered in transit?
Sign the archive hash with a private key before moving the file across gaps. The offline host then checks that signature using a stored public key before unpacking.
Why do engineers still need live database sessions in airgapped systems?
Automated scripts can fail when local data shapes differ from staging test data. Engineers must log in to inspect state, fix failed migrations, and check app health.