Requirements and Getting the Image

Documentation for the image tag 1.0.0-rc1. See Versions for the documentation of a release.

Requirements and Getting the Image

What you need

Item	Notes
A Linux, macOS or Windows host with Docker (Engine or Desktop) and Docker Compose v2	Container deployments
About 1 GB free RAM and a few GB of disk	The database is SQLite; growth is slow
A stable host name or IP address	Qertum bakes it into every URL it advertises. Changing it later changes the OIDC issuer and ACME directory URL
Free TCP ports	Single container: 8080–8083. Multi container: 8080–8084
A way to keep /data safe and backed up	See Backup and Restore

For a source build or local development you also need the .NET 10 SDK and, for the full stack, the Aspire CLI 13.6 or newer. See Local Development.

Optional:

• A TLS-terminating reverse proxy (Caddy, Traefik, nginx) for the web UI, identity and API: TLS and Reverse Proxy.
• A TPM 2.0 chip if you want the key ring sealed to hardware.
• An external OpenID Connect provider if you do not want to use the built-in one.

Getting the image

Qertum runs from a container image. There are two ways to get one.

Build it from the source tree

From the root of the Qertum source checkout:

# single container
docker build -f deploy/single-container/Dockerfile -t qertum:local .

# multi container (one image serves all services)
docker build -f deploy/multi-container/Dockerfile -t qertum-services:local .

The build needs network access to pull the .NET base images and compiles everything inside Docker; no local .NET SDK is required for this.

Pull it from a registry

Qertum publishes the same two multi-architecture images (linux/amd64 and linux/arm64) to three public registries:

Deployment	Docker Hub	Quay.io	GitHub Container Registry
Single container	qertum/qertum	quay.io/qertum/qertum	ghcr.io/qertum/qertum
Multi container	qertum/qertum-services	quay.io/qertum/qertum-services	ghcr.io/qertum/qertum-services

docker pull qertum/qertum:1.0.0-rc1
# or: docker pull quay.io/qertum/qertum:1.0.0-rc1
# or: docker pull ghcr.io/qertum/qertum:1.0.0-rc1

All three registries carry identical images; use whichever suits you. For the multi-container deployment, set QERTUM_IMAGE to the qertum-services reference, for example qertum/qertum-services:1.0.0-rc1. If your organisation mirrors the images into a private registry, use that reference instead.

Pin a specific tag instead of latest so that you control when you upgrade, and so you can roll back. See Upgrading.

Software bill of materials

Each GitHub release attaches a CycloneDX SBOM for each image (sbom-qertum-<tag>.cdx.json and sbom-qertum-services-<tag>.cdx.json). It lists what is inside the image: the base operating system packages, the .NET runtime and the NuGet packages. Their checksums are in the release's SHA256SUMS, next to the deploy bundle's. Feed the file to your vulnerability scanner or inventory tool. It describes the image as published; it is not signed.

Which version am I running?

Use the same release of the image and of this documentation. The wiki keeps a copy of the documentation for each release; see Versions.