Maintaining the metadata runtime image

For deployment, compatibility, optional datatype dependencies and custom images, see the administrator guide.

Publishing official images

.github/workflows/metadata_image.yaml defines publication to quay.io/galaxyproject/galaxy-job-execution, using the existing upstream QUAY_USERNAME and QUAY_PASSWORD credentials. Registry maintainers must create the repository, allow those credentials to push, and make images readable by execution hosts. Pull requests and forks build without publishing or accessing registry credentials.

Pushes to dev, release branches and release tags build the corresponding source checkout. PR checks build both the checkout and the default stable PyPI runtime; integration tests always build the checkout.
Manual dispatch rebuilds a specified published stable package version. Use this for the initial 26.1.1 image and for runtime/base-image updates after packages are available on PyPI.
Each publication writes a moving Galaxy-version alias (for example 26.1.1 or 26.2.dev0) and a unique build tag <version>-r<workflow-run-number>.<attempt>. Do not reuse build tags. Pin the digest for deployment; the version alias can advance after rebuilds.
Images record the Galaxy version, source revision and build date in OCI labels. The workflow also produces provenance and an SBOM. The installed Python package manifest records the resolved runtime dependencies.

A pinned Galaxy version alone does not make successive builds byte-identical: base images, OS packages and other Python dependencies can change. Rebuild and validate for security updates, retain the previous digest for rollback, and update deployment references deliberately. Update the Dockerfile’s stable Galaxy/Python defaults and the manual-dispatch default when adopting a new stable release. Do not silently substitute a new Galaxy release in an existing server deployment.