Pulling Images

Pulling Images

Where the images live, how to authenticate, and how to pin a version.

---

Current status

Everything on this page is live and verifiable today. What is not open yet is subscriptions — so if you do not already hold a token, the paid images exist but you cannot yet buy access to them.

		Status
Paid images	valenceruntimeimages.azurecr.io/runtime-*	✅ Published, private
Community images	ghcr.io/valence-works/runtime-ce-*	✅ Published, public — no login
Registry authentication	Registry token we issue you	✅ Enforced on paid images
Immutable version tags	<elsa-version>-build.<n>	✅ Paid line only
Non-root, chiselled base	Yes	✅ Live
Signing / SBOM / provenance	Published per image	✅ Live on both lines
Subscriptions	Buy a tier	❌ Not open yet — Editions and Support

If you pulled valenceworks/elsa-pro-* from Docker Hub, those images still work and are not going anywhere — but they are no longer updated. New builds publish to the two registries above: Community to GHCR, paid to Azure Container Registry.

---

Community images (free)

Public on GHCR. No authentication, no account, no signup.

docker pull ghcr.io/valence-works/runtime-ce-combined:latest
docker pull ghcr.io/valence-works/runtime-ce-server:latest
docker pull ghcr.io/valence-works/runtime-ce-studio:latest

These are the same build the paid tiers get — same layers, same digest, same hardening. Nothing is stripped out or deliberately degraded.

What a subscription adds is commitments, not different bits:

	Community	Paid
Image contents	Identical	Identical
Security patch commitment	None	Yes
Bug reports triaged	Public queue, no commitment	Committed window
Backports to your pinned line	—	Priority and above
Immutable tags	No — latest and <elsa-version>, both move	<elsa-version>-build.<n>

The tag difference is the one that matters in practice. Community publishes only moving tags, so a Community deployment cannot be pinned to an exact build. That is the line between evaluating and developing freely — which you are welcome to do indefinitely — and depending on this commercially.

If you subscribe later, you keep running the same image: no migration, no revalidation, you simply gain the commitments and the immutable tags.

→ Editions and Support

---

Paid images

Private, on Azure Container Registry (valenceruntimeimages.azurecr.io). Access is granted by subscription — there are no license keys or activation in the software itself; your registry credentials are the license.

You do not need an Azure account, a Microsoft account, or a GitHub account. We issue you a registry token — a username and password that work with docker login and nothing else. It has pull access to the three paid images and no other permission.

1. Receive your token

Issued when your subscription starts. It looks like:

username: your-organisation
password: <84-character string>

Treat the password like any other credential: store it in your secret manager, not in a repository.

2. Log in

echo "$VALENCE_REGISTRY_PASSWORD" | \
  docker login valenceruntimeimages.azurecr.io -u YOUR_TOKEN_NAME --password-stdin

Piping via --password-stdin keeps it out of your shell history. Don't pass it with -p.

3. Pull

docker pull valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413
docker pull valenceruntimeimages.azurecr.io/runtime-server:3.8.0-preview.5413
docker pull valenceruntimeimages.azurecr.io/runtime-studio:3.8.0-preview.1667

Studio carries a different version number from the other two — see Tags below.

Access rules

• Your token grants pull only, on the three paid repositories. It cannot push, and cannot see anything else in the registry.
• Access follows your subscription. The token password carries an expiry date aligned to your subscription period, so access lapses on its own if a renewal does not happen — and is reissued when it does.
• Do not share credentials. Each legal entity needs its own subscription — see the commercial license. Tokens are per-subscriber, so a shared credential is traceable.
• Revocation takes effect within about a minute.
• Images already pulled keep working — there is no phone-home, no kill switch, and no telemetry.

⚠️ docker login succeeding does not by itself prove you have access. The registry issues a token to any well-formed credential and checks permissions when you actually pull. If you are diagnosing an access problem, test a docker pull, not a login.

In CI

GitHub Actions, with the token stored as a secret:

- name: Log in to the Valence registry
  uses: docker/login-action@v3
  with:
    registry: valenceruntimeimages.azurecr.io
    username: ${{ secrets.VALENCE_REGISTRY_USERNAME }}
    password: ${{ secrets.VALENCE_REGISTRY_PASSWORD }}

Kubernetes, as an image pull secret:

kubectl create secret docker-registry valence-registry \
  --docker-server=valenceruntimeimages.azurecr.io \
  --docker-username=YOUR_TOKEN_NAME \
  --docker-password="$VALENCE_REGISTRY_PASSWORD"

spec:
  imagePullSecrets:
    - name: valence-registry
  containers:
    - name: elsa
      image: valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413-build.62

---

Tags

Tags derive from the Elsa version the image was built against, so the tag answers "which Elsa is in this image?" on its own.

Tag	Example	Moves?	Line	Use for
<elsa-version>-build.<n>	3.8.0-preview.5413-build.62	❌ Never	Paid	Production. Exactly one build, forever
<elsa-version>	3.8.0-preview.5413	✅	Both	Newest image for that Elsa build
sha-<commit>	sha-c7fc5a6	❌ Never	Paid	Reproducing an exact build when debugging
latest	latest	✅	Both	Local experiments only

While Elsa 3.8 is in preview, the Elsa version carries a -preview.<n> suffix, so the tags do too. Plain semver tags (3.8.1, 3.8, 3) are cut from release tags and do not exist yet; a 3.8-stable moving pointer only becomes meaningful once 3.8 is GA. Until then, <elsa-version>-build.<n> is the immutable tag to pin to.

⚠️ runtime-studio is versioned on Elsa Studio, not the engine, and the two preview numbers advance independently. At the time of writing, server and combined are on 3.8.0-preview.5413 while studio is on 3.8.0-preview.1667. Do not assume one tag string works for all three images — read each repository's tags rather than copying a tag across.

Pin in production

# ✅ Immutable — you get the same bits every time
image: valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413-build.62

# ⚠️ Moves — fine if you have tested rollback
image: valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413

# ❌ Never
image: valenceruntimeimages.azurecr.io/runtime-combined:latest

Pin harder with a digest, which survives even a tag being force-pushed:

docker inspect --format='{{index .RepoDigests 0}}' \
  valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413-build.62

image: valenceruntimeimages.azurecr.io/runtime-combined@sha256:abc123…

Which Elsa version is in an image?

docker inspect valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413-build.62 \
  --format='{{index .Config.Labels "org.opencontainers.image.description"}}'

---

Verifying images

Every image is signed with cosign, keylessly, and carries an SPDX SBOM and SLSA build provenance as attestations. Community images are signed too — they are the same build.

# Verify the signature
cosign verify valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413-build.62 \
  --certificate-identity-regexp='.*valence-works.*' \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

# Fetch the SBOM
cosign download sbom valenceruntimeimages.azurecr.io/runtime-combined:3.8.0-preview.5413-build.62

A successful verification prints the signing identity — the GitHub Actions workflow that built the image. Check that it is what you expect: a signature only tells you who signed, so a verification that passes against any identity you did not specify has told you nothing.

Your subscription token is enough to verify; no additional access is needed.

Verifying in-cluster before admission is the point of this — expect to wire it into an admission controller or your CI gate.

---

Platforms

Images are built for linux/amd64 and linux/arm64, so Apple Silicon and Graviton work natively. Docker selects the right one automatically; force it with --platform linux/amd64 if you need to.

---

Next: Running the Images · Configuration · Production Checklist