Why internal mirrors?

Every Axiom node runs jobs inside a container built from a Node Image. That image needs Python packages, system libraries, container base layers, and sometimes npm modules, Conda packages, or PowerShell tooling. In production, you don't want every build pulling from pypi.org, Docker Hub, or npmjs.com — that's slow, unreliable, subject to rate limits, and a supply chain risk.

Internal mirrors solve all of this: packages are cached locally, builds are reproducible offline, and every package is explicitly approved before it enters your fleet.

The seven mirrors

The package lifecycle

Regardless of ecosystem, every package flows through the same controlled pipeline. Click Next Step to trace the path.

One workflow, seven ecosystems

The operator experience is identical regardless of package type. In the Smelter Registry, you approve an ingredient — specifying its ecosystem (PyPI, APT, apk, OCI, npm, Conda, or NuGet), name, and version. The mirror service proactively fetches it using the appropriate backend. When you build a Node Image in the Foundry, only approved-and-mirrored packages are available.

How devpi works

devpi is a caching proxy that sits between your image builds and pypi.org. The first time a package is requested, devpi fetches it from upstream and stores a local copy. Every subsequent request is served from cache.

It runs as a Docker container alongside the Axiom stack on port 3141.

One-time setup

If devpi isn't in your compose file yet, add this service:

devpi:
  image: devpi/devpi-server:latest
  restart: unless-stopped
  ports:
    - "3141:3141"
  volumes:
    - devpi-data:/data
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:3141/+api"]
    interval: 30s
    retries: 3

Configure the mirror URL

Adding Python packages

You don't add packages to devpi directly. Approve them in the Smelter Registry (Module 6) and the mirror service proactively runs pip download to cache them. When Foundry builds an image that includes those packages, it pulls from devpi — fast, cached, and verified.

For air-gapped environments, upload .whl files directly via the Smelter's upload button.

APT — Debian & Ubuntu

apt-cacher-ng is a transparent caching proxy. All apt-get install calls during Foundry builds are routed through it. Packages cache on first fetch; subsequent builds are instant.

apt-mirror:
  image: sameersbn/apt-cacher-ng:latest
  restart: unless-stopped
  ports:
    - "3142:3142"
  volumes:
    - apt-cache-data:/var/cache/apt-cacher-ng
  environment:
    - DISABLE_IPFORWARD_CHECK=1

Configure the URL in Admin → Smelter Registry → Mirror Config: http://apt-mirror:3142

Foundry injects a temporary APT proxy directive into every Dockerfile, then removes it from the final image so the config doesn't leak to deployed nodes.

apk — Alpine Linux

Alpine uses apk, not APT. There's no apt-cacher-ng equivalent, but an nginx reverse-proxy cache does the same job. It sits between your builds and dl-cdn.alpinelinux.org, caching .apk files on first fetch.

apk-cache:
  image: nginx:alpine
  restart: unless-stopped
  ports:
    - "3143:80"
  volumes:
    - ./apk-cache.conf:/etc/nginx/conf.d/default.conf:ro
    - apk-cache-data:/var/cache/apk-proxy

proxy_cache_path /var/cache/apk-proxy
    levels=1:2 keys_zone=apk:10m
    max_size=10g inactive=7d;

server {
    listen 80;
    location / {
        proxy_pass       http://dl-cdn.alpinelinux.org;
        proxy_cache      apk;
        proxy_cache_valid 200 7d;
        proxy_cache_use_stale error timeout updating;
    }
}

Foundry injects a temporary /etc/apk/repositories rewrite pointing at the cache during builds, then restores the default repos in the final image — same pattern as the APT proxy.

Proactive package fetching

Both APT and apk mirrors can also work proactively. When you approve a system package in the Smelter, the mirror service fetches it ahead of time:

This means packages are already cached before any Foundry build runs — important for air-gapped environments where you pre-warm while you still have internet, then disconnect.

The problem with upstream registries

One-time setup: pull-through cache

Docker's official registry:2 image has built-in pull-through cache support. One environment variable turns it into a transparent proxy for Docker Hub:

registry-cache:
  image: registry:2
  restart: unless-stopped
  ports:
    - "5000:5000"
  volumes:
    - registry-cache-data:/var/lib/registry
  environment:
    - REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io

To also cache GHCR images, you can add a second registry instance pointing at https://ghcr.io.

Proactive image caching

When you approve a container base image in the Smelter (ecosystem: OCI), the mirror service proactively pulls it:

npm — Verdaccio

If your node images run JavaScript/TypeScript jobs, Verdaccio provides a lightweight npm registry that caches packages from npmjs.com on demand.

verdaccio:
  image: verdaccio/verdaccio:5
  restart: unless-stopped
  ports:
    - "4873:4873"
  volumes:
    - verdaccio-data:/verdaccio/storage

Verdaccio works like devpi: first install caches the package, subsequent installs serve from local storage. When you approve an npm ingredient in the Smelter, the mirror service proactively runs npm pack <pkg>@<version> to pre-warm the cache.

In Foundry blueprints, set the npm registry in the Dockerfile: npm config set registry http://verdaccio:4873

Conda — Data Science packages

For data science workloads that depend on Conda packages (numpy, pandas, scikit-learn, etc.), you can mirror specific packages and versions locally.

Two approaches:

When you approve a Conda ingredient in the Smelter, the mirror service runs conda create --download-only -n tmp <pkg>=<version> in a throwaway container to fetch the package into the local mirror. The Foundry injects a .condarc pointing at the local mirror during builds.

PowerShell — BaGet

For Windows automation jobs that need PowerShell modules (Pester, PSScriptAnalyzer, custom internal modules), BaGet provides a lightweight NuGet v3 server.

baget:
  image: loicsharma/baget:latest
  restart: unless-stopped
  ports:
    - "5555:80"
  volumes:
    - baget-data:/var/baget
  environment:
    - ApiKey=AXIOM-INTERNAL-NUGET-KEY
    - Storage__Type=FileSystem
    - Storage__Path=/var/baget
    - Database__Type=Sqlite
    - Database__ConnectionString=Data Source=/var/baget/db/baget.db
    - Search__Type=Database

BaGet requires packages to be pushed to it. When you approve a NuGet ingredient in the Smelter, the mirror service downloads the .nupkg from PSGallery and pushes it to BaGet automatically. You can also upload .nupkg files manually via the Smelter upload button.

In Foundry tool recipes, register the repository:

RUN pwsh -Command "Register-PSRepository \
  -Name 'AxiomInternal' \
  -SourceLocation 'http://baget:5555/v3/index.json' \
  -InstallationPolicy Trusted"

What the Smelter gives you

Approving a package (any ecosystem)

The workflow is identical whether you're approving a Python package, an Alpine system library, or a Docker base image.

Proactive fetch: how each ecosystem mirrors

Air-gapped uploads

If your environment has no internet, upload package files directly via the Smelter. Every ingredient row has an upload button. Upload the file (.whl, .deb, .apk, .nupkg, .tar.gz, .tgz) and the mirror status changes to MIRRORED immediately.

Enforcement modes

Switch modes via the enforcement dropdown at the top of the Smelter Registry tab.

The three building blocks

Creating a Runtime Recipe

All of this happens in the dashboard at /templates.

Building the Node Image

Bill of Materials

After a successful build, click BOM on any template to see every installed package — pip, apt, apk, npm, conda. The BOM Explorer in Admin lets you search across all built images: "which nodes have numpy 1.26?"

Dashboard health checks

The Smelter Registry tab shows a Repository Health card with live metrics for all configured mirrors:

Common problems

End-to-end checklist