Introduction
Updating software packages is a routine part of server maintenance. In an internet-connected environment, a package manager can usually contact a repository, download the required packages, verify them, and install the updates.
Air-gapped environments are different.
A server may have no direct internet access because of security, compliance, or network-isolation requirements. That creates a practical problem when the operating system or application needs a package update.
You cannot simply run a normal package installation command and expect the server to download the required files.
AWS has introduced Frozen Package Management for scenarios where package updates need to be prepared and delivered to systems that cannot directly access external package repositories. The underlying idea is to separate package acquisition from package installation so that updates can be moved through a controlled path.
This article explains the problem frozen package management addresses, how an air-gapped update workflow can be structured, how to validate packages before installation, and what teams should consider when operating isolated infrastructure.
Why Air-Gapped Servers Are Difficult to Update
A normal package update looks roughly like this:
Server
|
v
Package Manager
|
v
Internet Repository
|
v
Download Package
|
v
Install Update
An air-gapped server cannot follow that path.
Instead:
Air-Gapped Server
X
|
X Internet
The server may still need security fixes, runtime updates, libraries, or operating-system packages.
The challenge is therefore not simply downloading a package.
You also need to control:
Where the package came from
Which version was approved
Whether dependencies are included
Whether package signatures are valid
Whether the package has been modified
How the package enters the isolated environment
Which systems are allowed to install it
How the change is recorded
What Is Frozen Package Management?
The term frozen package management describes an approach in which the package set used by an isolated environment is deliberately prepared and controlled instead of allowing the server to resolve arbitrary packages from the internet.
The basic concept is:
Connected Environment
|
v
Resolve Packages
|
v
Freeze Approved Set
|
v
Validate
|
v
Controlled Transfer
|
v
Air-Gapped Environment
|
v
Install
The word frozen is important.
The isolated environment should not continuously change its package source based on whatever happens to be available online.
Instead, the team creates an approved package set and moves that set through the organization's controlled software-supply-chain process.
Why Freeze the Package Set?
Consider a server that needs:
Package A 1.4
Package B 3.2
Package C 7.1
If the server could access a live repository, a dependency resolution operation might produce a different result later because newer package versions or dependency changes become available.
A frozen package set provides a known state.
For example:
Application Release 42
Package A → 1.4.2
Package B → 3.2.7
Package C → 7.1.1
That gives the operations team a reproducible package baseline.
If another server needs the same environment, the approved package set can be reused rather than independently resolving dependencies.
A Practical Air-Gapped Update Workflow
A production workflow can be divided into several stages.
Step 1: Identify Required Updates
Start from the isolated environment.
Determine which packages require updates and why.
For example:
Security Update
|
+-- Package A
+-- Package B
+-- Dependency C
Avoid downloading unrelated packages simply because newer versions exist.
A smaller package set is easier to validate and audit.
Step 2: Resolve Dependencies Outside the Air Gap
Use an approved connected environment to resolve the required package versions.
For example:
Requested:
Package A 2.1
Dependencies:
Package B 4.7
Package C 1.9
The complete dependency graph should be captured before transfer.
Step 3: Freeze the Package Set
Record the exact versions that will enter the isolated environment.
For example:
package-a-2.1.4
package-b-4.7.2
package-c-1.9.8
Do not allow the isolated server to silently resolve newer versions later.
Step 4: Validate the Packages
Before transfer, verify:
Package source
Version
Signature
Integrity
Dependencies
Security status
Compatibility
A package should not enter the air-gapped environment simply because its filename looks correct.
Step 5: Transfer Through the Approved Boundary
The package set should cross the air gap using the organization's approved transfer process.
The exact mechanism depends on the security architecture.
The transfer itself should be recorded.
Step 6: Install From the Approved Package Set
The isolated server installs the frozen package set rather than reaching out to an external repository.
Step 7: Verify the Result
After installation:
Verify Package Versions
|
v
Run Application Tests
|
v
Check Service Health
|
v
Record Result
The update is not complete until the system has been validated.
Why Package Integrity Matters
Package management in an air-gapped environment creates a different security boundary.
The server cannot independently retrieve the package from its normal source, so the organization must have confidence in the package before it enters the environment.
Consider a package:
example-package-2.4.1
The package should be associated with an expected integrity value.
Conceptually:
Expected Hash
|
v
Transferred Package
|
v
Calculate Hash
|
v
Compare
If the values do not match, stop the installation process.
This does not replace package-signing or source-validation mechanisms, but it provides an additional integrity check.
Package Signatures
Hash verification answers:
Is this file the same file that was transferred?
Package signatures address a different question:
Was this package signed by a trusted publisher or signing identity?
Where the package ecosystem supports signing, signature validation should be part of the package-ingestion process.
The exact commands and trust model depend on the operating system and package manager.
The general process is:
Download
|
v
Verify Source
|
v
Verify Signature
|
v
Verify Integrity
|
v
Approve
|
v
Transfer
Dependency Management in an Air-Gapped Environment
Dependencies are one of the easiest parts of an offline update to overlook.
Suppose the application needs:
Package A
|
+-- Package B
|
+-- Package C
|
+-- Package D
Transferring only Package A is not enough if the target environment does not already contain compatible versions of B, C, and D.
A proper frozen package set includes the required dependency closure.
The result might be:
Approved Set
├── A 2.1.4
├── B 4.7.2
├── C 1.9.8
└── D 5.0.3
This makes the installation more predictable.
Version Pinning
Version pinning is particularly important for isolated environments.
Instead of:
Install latest Package A
use an explicitly approved version:
Package A = 2.1.4
This prevents an update process from unexpectedly selecting a different package version.
It also improves reproducibility.
If the same package set is installed on another isolated server, the team can reproduce the same software state.
Example: Linux Application Server
Imagine an application running on an isolated Linux server.
The current environment contains:
Runtime 8.0.x
Library A 3.4.1
Library B 2.8.0
A security advisory requires Library A to be updated.
The connected staging environment resolves:
Library A 3.4.7
Library B 2.8.0
The team validates the package set and transfers the approved artifacts.
The isolated server then installs exactly:
Library A 3.4.7
rather than asking a repository for whatever version happens to be available at installation time.
Keep an Inventory of the Frozen Set
Each package set should have an identifiable release or bundle.
For example:
Bundle: SECURITY-2026-10-01-01
Packages:
- package-a 2.1.4
- package-b 4.7.2
- package-c 1.9.8
Environment:
- Production-Isolated-01
Approval:
- Security Review Complete
Status:
- Approved
This information makes future audits and incident investigations easier.
Using an Internal Package Repository
Air-gapped does not necessarily mean every package must be copied individually to every server.
An organization may maintain an internal repository or package mirror inside the isolated network.
The workflow can then become:
External Source
|
v
Security Validation
|
v
Approved Package Repository
|
v
Air-Gapped Servers
The internal repository becomes the controlled source of approved packages.
The same principles still apply:
Version control
Package validation
Access control
Integrity verification
Change records
Retention
Production Rollout Strategy
Do not update every isolated server simultaneously unless the environment specifically requires it.
A staged rollout can reduce operational risk.
For example:
Package Bundle
|
v
Test Environment
|
v
Canary Server
|
v
Small Production Group
|
v
Remaining Servers
After each stage, verify:
Application health
Service startup
Dependency behavior
Logs
Monitoring
Performance
Security status
This is especially important for runtime and operating-system packages.
Common Mistakes
Downloading Only the Requested Package
Dependencies may be missing.
Always resolve the complete package set required by the target environment.
Installing From an Uncontrolled USB Drive
Physical transfer does not automatically make a package trustworthy.
Use the organization's approved transfer process and validate the package before installation.
Using Floating Versions
Avoid instructions such as:
Install latest version
in production package procedures.
Use explicitly approved versions.
Skipping Signature Verification
A package can be transferred successfully and still be untrusted.
Validate the package according to the package ecosystem's security model.
Updating Without Testing
Even a security update can change behavior.
Test the application after the package update.
Forgetting the Package Source
An audit should be able to answer where the package originated and why that version was approved.
Troubleshooting
Package Installation Reports a Missing Dependency
Check the frozen package set.
The dependency may not have been included, or the target environment may contain an incompatible version.
Package Verification Fails
Stop the installation.
Check:
File integrity
Transfer process
Expected hash
Package signature
Source artifact
Do not bypass the validation simply to complete the deployment.
Application Fails After the Update
Compare the old and new package sets.
Then inspect:
Application logs
Startup errors
Configuration changes
API compatibility
Runtime behavior
Native dependencies
If the issue is serious, use the organization's rollback process.
Different Servers Have Different Package Versions
This usually indicates that package management is not sufficiently controlled.
Compare inventories and restore servers to the approved package baseline.
Best Practices
Freeze Exact Versions
Record the package versions before entering the air-gapped environment.
Validate Before Transfer
Do not use the isolated server as the first place where package integrity is checked.
Preserve Provenance
Record the package source, version, validation status, and approval information.
Use Least Privilege
The account performing package installation should have only the permissions necessary for the task.
Automate Verification
Where possible, automate:
Version Check
|
v
Hash Check
|
v
Signature Check
|
v
Dependency Check
|
v
Install
Automation reduces manual mistakes.
Keep Rollback Information
Know which package versions were installed before the update.
Without a previous known-good state, troubleshooting becomes more difficult.
Advantages of Frozen Package Management
Makes air-gapped package updates more predictable.
Provides explicit package-version control.
Helps create reproducible environments.
Reduces dependence on live external repositories.
Supports controlled software supply chains.
Makes package provenance easier to document.
Helps security teams review packages before they enter isolated environments.
Can simplify auditing and change management.
Disadvantages and Limitations
Requires additional package-management processes.
Package sets must be prepared before installation.
Dependency resolution can become complex.
Security validation adds operational work.
Teams need a reliable transfer process.
Keeping multiple isolated environments synchronized requires discipline.
Emergency updates can be slower than updates in internet-connected environments.
When Should You Use This Approach?
Controlled or frozen package management is particularly useful when servers:
Cannot access the public internet.
Operate in highly restricted networks.
Require strict software provenance.
Need reproducible package versions.
Are subject to compliance or audit requirements.
Run critical workloads where uncontrolled package updates are unacceptable.
It is less useful for ordinary development machines where direct repository access is permitted and the additional package-control process would create unnecessary overhead.
Summary
Updating packages on an air-gapped server is not simply an offline version of a normal package installation.
The organization needs a controlled process for resolving dependencies, freezing versions, validating artifacts, transferring approved packages, installing them, and verifying the resulting environment.
A practical workflow is:
Identify
↓
Resolve
↓
Freeze
↓
Validate
↓
Transfer
↓
Install
↓
Verify
↓
Record
The key principle is to treat packages as controlled software artifacts rather than files that can be copied into an isolated server whenever an update is needed.
For AWS and other restricted environments, this approach provides a more predictable path for maintaining software while preserving the security and isolation requirements of the environment. It also creates the package provenance and reproducibility needed to troubleshoot changes and support operational audits.
Join the conversation! Your thoughts help the community grow.