Packaging

XTrinode uses separate version tracks for the control plane and the managed Trino runtime image. See Versioning for the current release line, component image tags, and included feature set.

Version Alignment

The XTrinode chart version fields, chart appVersion fields, umbrella chart dependency versions, and component image versions should stay aligned. The Trino runtime image tag is pinned separately because Trino compatibility is a runtime decision, not a control-plane release version.

GHCR Images

Control-plane images are published through GitHub Container Registry.

ghcr.io/xtrinode/xtrinode-operator:<version>
ghcr.io/xtrinode/xtrinode-api-server:<version>
ghcr.io/xtrinode/xtrinode-gateway:<version>

Use exact image tags for reproducible deployments. The current tags are listed in Versioning.

Public GHCR release images are currently published for linux/amd64. Local or private builds can set DOCKER_PLATFORMS in the main repository for other platforms, but the public release workflow does not publish arm64 images.

Helm Charts

The umbrella chart installs the operator, API server, gateway, and CRDs.

helm dependency build helm/xtrinode
helm upgrade --install xtrinode helm/xtrinode \
  --namespace xtrinode-system \
  --create-namespace \
  --set global.imageRegistry=ghcr.io/xtrinode

For release work, chart version, chart appVersion, and umbrella dependency versions should move together. After changing umbrella dependency versions, run helm dependency update helm/xtrinode in the main repository so helm/xtrinode/Chart.lock matches the new chart metadata.

GitHub Releases attach the packaged Helm charts:

xtrinode-<version>.tgz
xtrinode-operator-<version>.tgz
xtrinode-api-server-<version>.tgz
xtrinode-gateway-<version>.tgz

Release Tagging

Release tags are created by the main repository release workflow after a merged release PR passes CI. Tags use semantic versioning with a v prefix:

v<major>.<minor>.<patch>

Docker images use the component image version without the v prefix:

<major>.<minor>.<patch>

Cloud Support Position

Provider	Status
GCP/GKE/CAPG	Fully exercised cloud path
AWS/EKS/CAPA	Experimental provider-validation path with Terraform, registry/deploy material, API auth wiring, and tested node-pool resource generation
Azure/AKS/CAPZ	Experimental provider-validation path with Terraform, registry/deploy material, API auth wiring, and tested node-pool resource generation

The GCP path includes Terraform, GKE deployment material, Artifact Registry wiring, CAPI/CAPG material for per-runtime node pools, managed node-pool smoke coverage, and KEDA/resume smoke coverage. AWS and Azure have checked-in deployment material, while live CAPA/CAPZ parity remains tracked outside the GCP-supported flow.