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:

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:

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:

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:

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:

Do not bypass the validation simply to complete the deployment.

Application Fails After the Update

Compare the old and new package sets.

Then inspect:

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

Disadvantages and Limitations

When Should You Use This Approach?

Controlled or frozen package management is particularly useful when servers:

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.