Arsenal · Offline Image Packaging

STRATUM Container Appender

Build the datacenter before it leaves your facility. Package preinstalled virtual machines, appliance templates, ISO media, deployment definitions, and mission content alongside STRATUM in a versioned container image—ready to transport, approve, and deploy.

STRATUM APPENDER SOURCE ON GITHUB ↗

DATACENTER AS AN APPLICATION™

Build your datacenter once, then deliver it as an application

Stop treating remote datacenter deployment as a truckload of loose hypervisor installers, VM disks, ISO files, switch appliances, and post-install instructions. Assemble the approved infrastructure content before delivery and ship it with the STRATUM application. A deployed site receives the platform and its prepared workload content as one controlled release—not a scavenger hunt for missing images.

STRATUM Container Appender is our source-available utility for making that real. It adds customer-supplied files to an existing stratum-container.tar image archive as a new filesystem layer. The original image archive stays untouched. The output is a new, loadable image archive, preserving Docker-save or OCI+Docker hybrid format.

CONTENT PACKAGING

Package preinstalled VMs, templates, ISOs and datacenter content

Append the content your deployment needs. STRATUM Appender accepts file trees or prepared content-layer tarballs; it does not need a Docker daemon, a running STRATUM controller, a registry, an internet connection, or Go installed on the packaging host.

Content	What you can deliver
Installed VM disks	Prebuilt Linux or Windows workloads, network appliances, QCOW2 and VHD/VHDX images
Arsenal templates	Matching template YAML, icons and the files needed to offer prepared VMs in the target STRATUM version
Installation media	ISO images, firmware, drivers and deployment assets
Datacenter content	Exported topology definitions, site configuration, automation inputs and approved mission packages

For example, embed /stratum/addons/qemu/paloalto-8.1.0/virtioa.qcow2 and a matching template at /stratum/html/templates/intel/paloalto.yml. The destination receives the disk and its VM definition together. Follow the template naming, metadata, and discovery requirements of your target STRATUM release so the content is available for deployment; appending files alone does not register running VMs or automatically activate a datacenter.

Already have a library of STRATUM templates? Keep using it. Appender is for the extra images, configurations, and approved content your organization wants delivered inside the application from day one.

OFFLINE QUICK START

Append a ready-made VM and its template without a container runtime

Arrange the new files under their intended paths inside the container. The --source directory retains its relative file hierarchy; --dest / places that hierarchy at the image filesystem root.

example · prepared content directory

overlay/
└── stratum/
    ├── addons/qemu/paloalto-8.1.0/virtioa.qcow2
    └── html/templates/intel/paloalto.yml

Build the x86-64 or ARM64 executable from the GitHub repository, or use a trusted prebuilt binary. Then preview and append the content:

shell · offline append (x86-64 example)

# x86-64: use the prebuilt CLI (ARM64 binary is also available)
chmod +x ./stratum-container-append-linux-amd64

# Preview the content without writing a new image
./stratum-container-append-linux-amd64 \
  --input stratum-container-base.tar \
  --output stratum-container-custom.tar \
  --source ./overlay --dest / --dry-run

# Build one complete, loadable STRATUM image with a new content layer
./stratum-container-append-linux-amd64 \
  --input stratum-container-base.tar \
  --output stratum-container-custom.tar \
  --source ./overlay --dest /

Each successful invocation adds one new layer and produces a new, complete archive. Use a new output filename each time; the source archive is never overwritten. Repeat with the newly created archive as input when separate content groups should become separate layers.

shell · inspect and verify

# Inspect the customized image and its recorded layers
./stratum-container-append-linux-amd64 inspect \
  --input stratum-container-custom.tar

# Verify the complete archive before distributing it
sha256sum stratum-container-custom.tar

OCI LAYER DISTRIBUTION

Keep the base image; deliver only the layers that changed

Here's why this matters at enterprise scale. In an OCI+Docker hybrid image, existing layer blobs retain their SHA-256 content identities when STRATUM Appender adds a new layer. The output records a new layer and updated image metadata while leaving the previous layer bytes intact.

Publish that updated image to an OCI-aware registry, such as JFrog Artifactory, and use an OCI-compatible pull at the destination. A location that already holds the original layers does not need to download those unchanged blobs again. It retrieves the missing content layers and the new image metadata. A new manifest digest identifies the approved release.

BASE RELEASESTRATUM platform layersAlready on the ship / remote site

MISSION RELEASEAdded VM/template layerTransfer only if missing locally

NEXT UPDATENew content layer + manifestReuse all unchanged blobs

SHA-256 digests verify that transferred blobs match the manifest. They provide integrity checking; authentication, authorization, signing, and encryption remain responsibilities of the approved distribution system.

Design the layer boundaries deliberately. A layer represents the entire appended content group, not a file-level delta algorithm. Put independently updated mission packages or appliances in separate layers to prevent one small change from forcing the retransmission of a giant bundled layer.

NAVAL · EDGE · DISCONNECTED

A Navy use case: build ashore, deliver to the fleet, deploy aboard

Consider a Navy fleet with deployed ships connected through high-latency satellite links, intermittent networking, or controlled file-transfer channels. The wrong way to update a ship is to make it download a multi-gigabyte datacenter image every time somebody adds a VM or changes a mission package.

Build the datacenter ashore. Preinstall and harden the VMs, prepare the network appliances, define the intended topology, include any required ISO media, and package the approved content into STRATUM layers. Publish the release through the organization's application repository—an OCI-capable JFrog Artifactory deployment is one example.

Move only what's missing. Once a ship already has the base STRATUM image, an OCI-aware delivery path can reuse its existing layers. New mission content arrives as new blobs with SHA-256 identities and an updated manifest. Compatible clients can retry or resume transfers when links drop. When connectivity disappears, the already-delivered content remains locally available for deployment.

That is the payoff: instead of redistributing the full datacenter for every revision, ship the change. This model also applies to forward operating sites, industrial edge facilities, remote labs and any environment where bandwidth, latency and connection windows are operational constraints.

DELIVERY MODEL

Choose single-file delivery or layer-aware distribution

Appender prepares the image archive offline. Your existing distribution system decides how that release moves to each destination. These are different transfer modes:

Delivery method	What moves	Best use
OCI registry / JFrog Artifactory	Manifest and content-addressed blobs missing from the destination's image store	Bandwidth-efficient updates to sites that already have the base image
Complete image archive	The new `stratum-container.tar` OCI container image as one file	Air-gapped installs, removable media, first delivery and standard offline imports
SFTP / secure file transfer	Whole tar if you send a tar; separate blobs only if your transfer workflow exports and tracks them by digest	Controlled delivery channels and disconnected staging

Important: Appender itself writes a complete OCI container image archive. A raw SFTP transfer of that OCI image is not automatically an incremental layer transfer. To get the missing-layers-only advantage over SFTP or satellite file distribution, use an OCI-aware registry/client or a separate verified-by-digest blob transfer workflow.

Keep the running platform state separate from the versioned image, and use your normal STRATUM Arsenal and Mission Planner workflows to activate packaged content after import. Never bake live credentials or secret keys into public image layers; their contents can be recovered from distributed archives.

PUBLISHED SOURCE · CUSTOMER CONTROL

Own the packaging pipeline

The Appender source is public. Integrate it into a build pipeline, test it offline, add your own approval gates, inspect the finished archive, and distribute through your organization's existing infrastructure. The utility leaves the source STRATUM container image unchanged and never needs to start STRATUM or execute the included VM images.

Verify operating-system redistribution rights for embedded guest images, validate your templates and destination mount paths, and keep image signing and deployment authorization in your normal release process.