Harthelm 1.5.0

Released 2026-10-19. API version 0.12.0. A minor release with no database migration and no new value. Nothing needs to be done before the upgrade, and no store restarts: read Before you upgrade.

helm upgrade harthelm oci://<your registry>/charts/harthelm --version 1.5.0 -n harthelm-system -f my-values.yaml

Before you upgradeCopy Anchor Link

• Core and the router roll, as with every release: their image changes. Workspaces, services, PostgreSQL, MariaDB, Valkey, RabbitMQ and S3 keep running.
• No RabbitMQ broker and no S3 store restarts. The stores' start arguments are unchanged, and the new CORS answer lives in the router, so a domain that comes or goes needs no restart either.
• No values change. 1.5.0 adds no values key and the 1.4 chart's values file works as it is. Argo CD users move the pin to the 1.5 chart; nothing else belongs in the same commit.
• A log filter on the dump line may need a change. The tls field of a PostgreSQL dump now says what the dump used (see Changed): an alert that reads tls=false for PostgreSQL stops matching. The nightly run also has a new WARN line for a managed service it skips because it is still starting.
• hart 1.4 keeps working. Update it from the release's archives to match.

NewCopy Anchor Link

Browser uploads from your team's custom domains. A page on a verified custom domain of your team may now send presigned requests, uploads included, to a public S3 host of the same team. The router answers for the origin: it answers the preflight itself and adds the origin and the exposed headers (ETag, which a multipart upload needs, and the x-amz ids and checksums) to the store's answer. It never sends Access-Control-Allow-Credentials and never *. A domain of another team, an unverified or lapsed one and any other origin get nothing. Gated hosts and RabbitMQ's management host are as in 1.4. See Managed services.

The installation id for a fresh install. A licence bound to an installation names its id, which exists only after core's first start, and a fresh installation is restricted until a licence is in. Core now logs one INFO line at every start while no licence is in force, no licence installed; installation id <uuid>; see docs/license.md, and the notes of helm install print the command that finds it. The doctor's license check names the id in the same cases. The order of a fresh install, break-glass included, is in Install with Helm and Licence.

The doctor in the console. Platform → Doctor, between Capabilities and Licence, runs the same checks as hart admin doctor and shows them in the same order: each check's name, its status (ok, warn, fail, or skip, greyed out) and its detail, a count per status, when the checks ran and how long that took, and the command for a terminal. Opening the page runs the checks, and Run again runs them once more; the page never runs them on its own in the background. Only cluster admins see it. It has no switch for the capability probe: what the cluster offers stays on the Capabilities page, which the Doctor page links to. The API is unchanged; the page reads the same GET /admin/doctor. See Monitoring.

Strict-Transport-Security on the console. Core's public port sends Strict-Transport-Security: max-age=31536000 on every response, without includeSubDomains and without preload, and never for workspace hosts. There is no value to set. See Security.

More in the install guide. Install with Helm has the order of a fresh install; On-premises clusters has the nodes-without-a-load-balancer case (what trustedProxies is, how core reaches an issuer served by the same nodes) and local-path storage with its limits; Sign-in has Dex in front of GitHub; Workspaces lists the registry modes for container services; Network policies has the Cilium values, now a supported starting point that every release renders and checks against the Cilium schemas, with what each part is for.

ChangedCopy Anchor Link

• A nightly backup run skips a managed service that is still starting. A new instance reports where it listens seconds to minutes after it was created. A backup run that met one in between failed as a whole in 1.4, and so did its retry, although every other dump was written. The nightly run now skips such an instance with one WARN line, managed service not ready yet; skipped, with the fields service, driver, status and age (the instance's status, for example creating, and the time since it was created), writes no backup record for it and does not fail. The next night dumps it. A dump on demand of such an instance still fails, and so does a dump that fails for any other reason. An instance that never reports where it listens shows up in the doctor's managed-backups warning once it has had no dump for 26 hours. See Backups and restore.
• The dump log says the transport that was used. managed dump written carries tls (the transport the dumper actually used), tls_verify (server or none) and port. A PostgreSQL dump is tls=true tls_verify=none and a MariaDB dump tls=true tls_verify=server, whether or not the instance serves in-cluster TLS; in 1.4 both said tls=false without it. Where a line names the target itself, the flag is internal_tls now. See Backups and restore.
• The doctor's oidc check names a hint that fits the cause. A certificate error points to the CA, a DNS error to the resolver and networkPolicy.dns, a refused or timed-out connection to networkPolicy.egress.idp and the node-address trap without a load balancer; any other failure gets none. Until 1.4 every failure pointed to the CA. See Troubleshooting.
• The router logs its start-up reconnects at INFO. route stream ended, reconnecting is INFO (with startup and waited) for the first five minutes of a router that has not had a snapshot yet, the time core's startup probe gives core, and WARN after that and after any snapshot. The message, the other fields and the metric are unchanged.
• Every response of a public S3 host carries Vary: Origin, so no cache in front hands one origin's answer to another.

For operatorsCopy Anchor Link

The release channel. From 1.5.0 every stable release is also copied, unchanged and by digest, to the registry the hosted installations pull from; release candidates are not copied. For a self-hosted installation it changes nothing: the chart and the images you install are the same artifacts, with the same digests, from the places this documentation names, and images.txt still lists every image. A mirror or an air-gapped install is made as before (Air-gapped installs).

Metrics. The router counts the CORS answers on the gate metric with the endpoint cors and the results preflight, refused and request; its request log gains the field cors.

API 0.12.0. Unchanged.

Tests onlyCopy Anchor Link

These change what is checked before a release, not what it does: a kind test in which a team member without the single sign-on meets RabbitMQ's own login form, the same case as a router unit test and a test against the real broker, a run of the managed hosts test with a page on a custom domain that uploads through the public S3 host, and a kind test that opens the Doctor page and runs it twice. Nothing of them ships.

Known limitsCopy Anchor Link

• CORS for custom domains is for public hosts only. A page on a custom domain still cannot call a gated S3 host from a script (no cookie goes along, the gate answers 401); switch the store public or keep a forward route on the dev domain.
• The router's error pages carry no CORS headers. A script on a custom domain that meets a paused store (503) or a starting one sees a CORS error instead of the page's status.
• The dev hosts' CORS is still the store's own flag. Moving it into the router would restart every store once and is not done.
• Path-style only. Bucket names as host names (<bucket>.ms-42.…) are not served.
• The management UI's sign-in lasts one hour and is not renewed.
• Restores are runbooks. A button that restores a backup into a new instance is not in this release.