Phase 3: Internal Artifact Supply ChainOpen Source

SovAI Air-Gap Internal Artifact Hub

Build new AI applications from approved internal images, wheels, prompts, tools, and model references.

View GitHub Repository Request implementation help

Expected outcomes

Build new AI applications from approved internal sources instead of public internet dependencies

Control base images, Python packages, prompts, tools, model manifests, approvals, and checksums

Demonstrate an offline build pattern for governed AI application delivery

What it includes

Internal Docker registry pattern

Local Python wheelhouse

Prompt and approved tool registries

Approval and checksum records

Offline build sample app

Enterprise artifact supply chain notes

What this kit proves

These are the practical claims the kit demonstrates when run locally.

A local registry can serve approved base images.

A local wheelhouse can serve approved Python packages.

New apps can be built without direct public internet pulls.

Approvals and checksums can be stored alongside artifacts.

The same pattern can support RAG, ML, and agent applications.

Internal artifact supply is a separate product layer from the runtime app.

Internal artifact hub flow

Step 1

Start a local internal Docker registry on localhost:5000.

Step 2

Import approved base images while internet is available.

Step 3

Download Linux-compatible Python wheels into the local wheelhouse.

Step 4

Record approvals and checksums for imported artifacts.

Step 5

Build a new sample app using localhost:5000/sovai/python:3.11-slim.

Step 6

Install Python packages with --no-index from artifact-hub/wheelhouse.

Step 7

Run the sample app and confirm it was built from internal artifacts.

Quick start

Copy these commands into a terminal and follow the connected/offline steps described in the repository README.

git clone https://github.com/sovaihub-lab/sovai-airgap-ai-Internal-artifact-hub
cd sovai-airgap-ai-Internal-artifact-hub
chmod +x scripts/*.sh
./scripts/start-hub.sh
./scripts/import-base-images.sh
./scripts/import-python-wheels.sh examples/offline-build-sample-app/requirements.txt
./scripts/approve-artifact.sh container-image localhost:5000/sovai/python:3.11-slim "Approved Python base image"
./scripts/verify-artifacts.sh
cd examples/offline-build-sample-app
./scripts/build-offline.sh
./scripts/run.sh
open http://127.0.0.1:8095

Configuration

Internal registry

localhost:5000

Base image

localhost:5000/sovai/python:3.11-slim

Package source

artifact-hub/wheelhouse

Install rule

pip install --no-index --find-links /artifact-hub/wheelhouse

Ports and services

Service

Port

Purpose

Internal Docker Registry

5000

Approved container images

Wheelhouse Server

8081

Browse approved Python wheels

Artifact Server

8082

Browse prompts, tools, manifests, models

Sample App

8095

Offline-built app proof

Working proof

The demo should produce evidence like this when it is running correctly.

runtime_mode: offline-build-from-internal-artifacts
base_image: localhost:5000/sovai/python:3.11-slim
package_source: local-wheelhouse

Troubleshooting notes

Wheelhouse was empty

verify-artifacts.sh only verifies existing files. Run import-python-wheels.sh while connected before trying an offline build.

Windows wheels did not match Linux Docker runtime

The import script should download wheels inside a Linux python:3.11-slim container so packages such as pydantic-core match the target image.

Git Bash converted /work into C:/Program Files/Git/work

Use MSYS_NO_PATHCONV=1 and MSYS2_ARG_CONV_EXCL=* for Docker commands that mount Linux-style paths from Git Bash.

Docker registry push returned unknown error

On Windows, use a Docker named volume for registry storage instead of a Windows bind mount.

Limitations

This is a local proof of concept for artifact supply, not a production registry deployment.

Production use should add TLS, authentication, vulnerability scanning, SBOM generation, image signing, and RBAC.

The demo does not yet automate app template creation or promotion workflows.

Recommended next steps

Build Phase 4: Offline Build Factory

Add app templates, allowed dependency policies, validation scripts, SBOM generation, and promotion workflows.

Move toward Phase 5

Add enterprise controls such as role-based approvals, signed images, vulnerability gates, audit dashboards, and deployment promotion stages.