📋 Table of Contents
An air-gapped machine — one with no internet connection, by policy or by necessity — is common in secure facilities, industrial control rooms, labs, medical devices, and field equipment. Installing software on it is its own discipline: the convenient "download and run" path does not exist, and the small web-installer stubs most vendors hand you are useless without a connection. This guide lays out a repeatable, security-conscious workflow for getting software onto offline machines correctly: source the right installer, verify it, transfer it safely, install it, and keep it updated.
1 Step 1 — Source a real standalone installer (not a stub)
The single biggest air-gap mistake is grabbing a vendor's default download, which is often a 1–5 MB "web installer" that fetches the real payload at install time. On an offline box, it fails. You need the full standalone/offline installer — the complete application in one file (.exe/.msi on Windows, .dmg/.pkg on macOS, .deb/.rpm/.AppImage/.tar.gz on Linux). Many vendors publish these but bury them behind an "Other platforms," "Offline installer," or "Enterprise" link. Confirm by file size: a full installer is tens to hundreds of MB, a stub is a couple of MB. Always download from the publisher's own domain — for an air-gapped environment, a tampered installer is a worst-case scenario, so third-party mirrors are off the table.
2 Step 2 — Verify integrity and signature before it leaves the internet
Do verification on the connected staging machine, while you still have references. Two checks: (1) Hash — if the vendor publishes a SHA-256 checksum, compute it (certutil -hashfile file.exe SHA256 on Windows, shasum -a 256 file on macOS/Linux) and compare. (2) Signature — confirm the installer is digitally signed by the publisher (Properties → Digital Signatures on Windows; spctl -a -vv or codesign -dvv on macOS; gpg --verify against the vendor's published signature on Linux). Record the hash alongside the file so the offline side can re-verify after transfer. Skipping this step defeats the entire point of an air gap.
3 Step 3 — Transfer with controlled media
Move the verified installer using whatever your security policy allows — typically a dedicated, scanned USB drive, a one-way data diode, or an approved transfer kiosk. Best practices: use removable media reserved for this purpose (not someone's personal stick), scan it on the connected side, and re-compute the hash on the air-gapped side to confirm the file arrived bit-for-bit intact. If you deploy regularly, keep a single "software depot" folder structure on the media so transfers are predictable and auditable.
4 Step 4 — Install, ideally unattended
On the target, run the installer. For one machine, an interactive install is fine. For several, use the silent/unattended switches most full installers support: Windows MSIs take msiexec /i app.msi /qn, many EXE installers accept /S or /silent, macOS .pkg files install with sudo installer -pkg app.pkg -target /, and Linux packages install with the distro's package manager pointed at the local file. Capturing the exact silent command in a short runbook makes the next deployment a copy-paste rather than a fresh investigation. Our silent-install reference collects these switches for common tools.
5 Step 5 — Handle dependencies and runtimes
Offline installs fail most often on missing dependencies the installer assumes it can download: Visual C++ Redistributables and .NET runtimes on Windows, shared libraries on Linux, or a specific framework version. Before you transfer the main app, identify and stage its prerequisites too — vendors usually list system requirements, and you can pre-download the matching redistributables from the same official source. Bundling the runtimes with the app in your depot folder prevents the classic "installed fine on my online test box, failed on the air-gapped target" surprise.
6 Step 6 — Plan for updates
An air-gapped machine will never auto-update, so its software ages — and ageing software is a security liability. Build a cadence: on a schedule, re-download the current installer on the connected side, re-verify, and re-deploy through the same controlled-media process. Keep a simple inventory of what is installed where and at which version so you know what is due. Treat the offline installer depot as a living artifact, not a one-time copy.
Frequently Asked Questions
What is an air-gapped machine?
It is a computer deliberately kept off any network with internet access, isolated for security or reliability reasons. Because it cannot reach vendor servers, software must be brought in manually as complete offline installers.
Why do normal installers fail on offline machines?
Many vendors ship a small "web installer" that downloads the real application during setup. With no connection, that download fails. You need the full standalone/offline installer, which contains the entire application in one file.
How do I verify an installer is safe before transferring it?
On the connected staging machine, compare the vendor's published SHA-256 hash against the file you downloaded, and confirm the installer's digital signature names the publisher. Record the hash so you can re-verify after the file reaches the offline side.
How do I keep air-gapped software up to date?
Set a recurring schedule to re-download the current installer on a connected machine, re-verify it, and re-deploy through your controlled-media process. Keep an inventory of installed versions so you know what needs refreshing.
Conclusion
Deploying to air-gapped machines is less about any single trick and more about a disciplined chain: source the real standalone installer from the official domain, verify it before it leaves the internet, transfer it with controlled media, install it (ideally silently), stage its dependencies, and schedule updates. Get that workflow right once and every future deployment becomes routine. Our directory focuses on exactly the verified, official standalone installers this process depends on.
