Skip to main content

Upgrading

Breaking changes and the action each one requires, newest first. If a release is not listed, it had no breaking changes.

Before any upgrade, check which version you are on — see Verifying what you are running.


0.1.0 → 0.1.1

A security and reliability release.

Upgrade strongly recommended

The 0.1.0 prediction worker images do not start. All three (prediction-worker-xgboost, -lightgbm, -autogluon) fail on import:

ImportError: cannot import name 'configure_logging' from 'observability_init'

If you deployed 0.1.0, those three workers are in CrashLoopBackOff and prediction pipelines are unavailable. The rest of the product is unaffected.

Upgrade

helm repo update
helm upgrade dashboard actyze/dashboard --version 0.3.0 -n actyze

Chart 0.3.0 deploys appVersion 0.1.1.

If you pin image tags yourself, move them from 0.1.0 to 0.1.1 — the worker images in particular, for the reason above.

Three changes that may need action

1. The frontend container listens on 8080, not 80

The frontend now runs as an unprivileged user (uid 101), which cannot bind a port below 1024.

YouAction
Use the Helm chartNothing. The Service targets the named port http and resolves automatically.
Use the published Compose fileNothing. The mapping is already 3000:8080.
Wrote your own manifests, Service, Ingress or Compose file targeting container port 80 numericallyUpdate to 8080.
# before
ports:
- containerPort: 80
# after
ports:
- containerPort: 8080

The Service port is unchanged at 80, so commands like kubectl port-forward svc/dashboard-frontend 3000:80 still work. Only the port inside the container moved.

2. curl is no longer in the Python images

nexus, schema-service and the three prediction workers no longer ship curl. It existed only to run a container HEALTHCHECK and was itself a source of HIGH-severity CVEs.

The built-in healthcheck and the bundled Compose probes now use a Python stdlib request, so the default setup needs no change.

Action required only if you have a custom health check, readiness probe or sidecar that shells out to curl inside these containers. Use a Kubernetes httpGet probe, or:

python -c "import urllib.request,sys; sys.exit(0 if urllib.request.urlopen('http://localhost:8000/health', timeout=5).status==200 else 1)"

wget is available in the frontend image (busybox), but not in the Python images.

3. Containers run as a non-root user

Imageuid
nexus, schema-service, the three prediction workers10001
frontend101
trino1000

The chart sets a matching securityContext on every deployment — runAsNonRoot, seccompProfile: RuntimeDefault, allowPrivilegeEscalation: false, capabilities: drop: [ALL] — which satisfies the Kubernetes restricted Pod Security Standard.

Action required only if you mount a volume that was written by a previous root-running container. Files owned by uid 0 will not be writable. Either chown the volume contents to the new uid, or rely on fsGroup, which the chart already sets per service.

note

readOnlyRootFilesystem is available as a per-service toggle but defaults to false. Several services write scratch data (model cache, library caches) and need an emptyDir mounted over those paths before it can be enabled.

Everything else in 0.1.1 — no action needed

  • Base images moved to python:3.13-slim, and the frontend to nginx-unprivileged.
  • Images are multi-stage; compilers and build tooling no longer ship in the runtime layer.
  • schema-service no longer bundles the NVIDIA CUDA runtime it could not use. The image drops from 9.21 GB to 1.95 GB.
  • The xgboost worker uses the xgboost-cpu distribution — same import name and version, without the NVIDIA dependency.
  • Fixable CRITICAL/HIGH findings across the six images went from 91 to 8.

See Security & Privacy for the current posture.

Rolling back

helm rollback dashboard -n actyze

Rolling back to 0.1.0 restores the non-starting prediction workers, so prefer fixing forward unless the frontend port change is the blocker.


Getting help

If an upgrade does not go as described here, please open an issue with your chart version, appVersion, and the output of kubectl get pods -n actyze. For anything security-related, use private reporting instead.