Harthelm 1.6.2

Released 2026-10-23. API version 0.13.1 (descriptions only, no operation or field changed). A patch release with no database migration and one optional values key, git.allowedHosts. Upgrade as usual, and read Before you upgrade for the order of the chart and the new value.

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

Before you upgradeCopy Anchor Link

• Core and the router roll, as with every release. Nothing in the database changes.
• Set git.allowedHosts with the 1.6.2 chart, not before. The 1.6.1 chart's schema refuses the key. With a GitOps tool, move the chart version first or in the same change as the value. Empty or absent keeps 1.6.1's behaviour.
• hart 1.6.1 works against 1.6.2 without a warning (only the patch version of the API changed).
• Cluster admins see more. After the upgrade, the installation's cluster admins see every organization's Git providers in Account settings › Git connections, member or not (see below).

NewCopy Anchor Link

An allow-list of Git provider hosts. The operator can narrow the hosts an organization's owners may register their own Gitea or Forgejo at, with git.allowedHosts:

git:
  allowedHosts: [git.example.org, "*.forge.example.net"]

An entry is an exact host name or IP address, or *.example.org for every subdomain of example.org at any depth (not example.org itself). A host outside the list is refused when an owner registers a provider or changes its URL, with 422 git-provider-url-refused and a reason that names the list. The list comes after the address guard of 1.6.1 and only narrows it: localhost, link-local addresses and the other refused addresses stay refused whatever the list says. A provider registered before whose host is no longer on the list takes no new connections; the connections made before and the workspaces keep working, and the doctor's network-policy check names the provider. The installation's own providers (git.providers) are not checked against the list. See Git providers › An organization's providers.

Who sees an organization's providers. Account settings › Git connections and GET /git/providers list the installation's providers and those of every organization you may view: its members, and the installation's cluster admins for every organization. With providers of more than one organization, each organization's are listed under its name, after the installation's. Until 1.6.1 a cluster admin who was no member of an organization saw none of its providers, although they could register and retire them.

Each team its own providers. Create workspace and Git access offer the installation's providers and those of the team's organization only, so a cluster admin with many organizations sees the right ones for the team at hand.

ChangedCopy Anchor Link

• Clearer empty states. When Git connections, Create workspace or Git access find no Git provider, they say that an owner of the organization adds one under Members › Organization › Git providers, and that the installation's administrator can add providers for every organization.
• A refused connect says why. Connecting a provider whose host left the allow-list comes back to Git connections with the reason, and how to get the host allowed again.

Known limitsCopy Anchor Link

• Gitea and Forgejo only. GitHub as an organization's provider is still not in this release.
• No "test connection". A wrong client id or secret shows when the first member connects.
• The list is the operator's. Organizations see the refusal and its reason, not the list itself.