Some Indian deployments — defence, certain government systems, parts of critical infrastructure, occasionally a bank's most sensitive environment — run on networks with no route to the internet. Delivering software into one is a different discipline from ordinary on-premise work, and the difficulty is not security engineering. It is that every convenience your build and runtime quietly depend on has to be identified and removed.
Start with the build, because that is where most of the surprises are. Package managers fetching dependencies at install time, container images pulled from public registries, fonts and scripts loaded from a CDN, a language runtime downloading something on first use. Each works invisibly in a connected environment and fails in an isolated one, sometimes with an error that does not name the cause. The deliverable must be a complete artefact containing everything, verified by building and running it on a machine with networking disabled — which is the only honest test.
Licensing is the next thing to reconsider. Any scheme that phones home to validate a key does not work here, and neither does a subscription check with a grace period, because the grace period expires. Offline licensing — a signed file with an expiry, validated locally — is the workable approach, and it needs designing early because retrofitting it means changing how the product starts.
Then updates, which become a logistics problem rather than a pipeline one. Patches travel on physical media through an approval process that may take weeks, applied by the customer's staff, possibly by someone unfamiliar with the product. That means each update must be self-contained, must be applicable without internet access, must state its prerequisites, and must be reversible by someone following written instructions. It also means your release cadence into these environments is measured in quarters, and supporting several versions simultaneously is unavoidable.
Support without visibility is the hardest part operationally. No logs you can see, no telemetry, no screen share, and possibly no ability for the customer to send you a file. What you can do is build a diagnostic bundle the customer generates and reviews before releasing it — because they will want to inspect what leaves — plus verbose local logging, a health check with human-readable output, and documentation written for someone who cannot ask you a question in real time.
Price and scope this deliberately. Air-gapped delivery carries packaging effort, long release cycles, version proliferation, and a support model that is slower and more expensive per incident. It also has very little competition, which is the commercial reason to do it. What fails is accepting an air-gapped requirement inside an ordinary on-premise contract, at ordinary prices, on the assumption that it is the same work with the network switched off.
