Image access

Mildport container images are private, and they stay that way. Access is granted per customer to a GitHub account you nominate — there is no public pull, and nothing about your deployment becomes visible to anyone else.

Requesting access takes a minute. Granting it is a manual step on our side — done within one business day rather than as an instant unlock.

Request access

1. Open Self-hosting in your account.
2. Enter the GitHub username that will pull the images. A personal account is fine; a machine account is better if your CI does the pulling.
3. Request access. The page shows it as pending, and flips to granted once we’ve done it.

Paid plans only

Self-hosting comes with paid plans — the free tier is the cloud trial. Upgrade on the Licenses page first and the request unlocks.

Pick the account deliberately. Changing it after a grant needs a word with support, because the grant is tied to that specific GitHub identity.

Pull the images

Once the page says granted, authenticate with a GitHub personal access token carrying the read:packages scope:

echo $GITHUB_TOKEN | docker login ghcr.io -u <your-github-username> --password-stdin

Then pull what you need:

docker pull ghcr.io/capitality-io/mildport-aio    # engine + decode sidecars, one image
docker pull ghcr.io/capitality-io/mildport        # engine only
docker pull ghcr.io/capitality-io/mildport-embed  # semantic matching (optional)

The Helm chart lives beside them and uses the same login:

helm install mildport oci://ghcr.io/capitality-io/charts/mildport \
  -n mildport --create-namespace -f values.prod.yaml

On Kubernetes, put those credentials in an imagePullSecret and reference it from your values — the cluster nodes do the pulling, not your laptop.

Which tag to run

Tags match the versions on the changelog, so “what am I running?” and “what changed?” always line up. Pin an explicit version in production and upgrade deliberately; latest is convenient for a first look and a poor idea for a deployment you rely on.

Each promoted digest carries a software bill of materials. Verify our images — including the offline path for an air-gap.

Staying current

New versions are announced in the changelog. The engine has no telemetry and never phones home, so it will not tell you a new version exists — upgrading stays your decision, on your schedule.

The upgrade itself is a tag bump: pull, roll out, done. Your license keeps working across upgrades, because it is verified locally rather than re-activated.

Next: Self-hosting overview · Air-gapped deployment