Harthelm 1.6.1

Released 2026-10-23. API version 0.13.0 (five operations and two fields added). A patch release with one feature and one database migration that only adds; no values change. Upgrade as usual, and read Before you upgrade for the rollback.

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

Before you upgradeCopy Anchor Link

• Core and the router roll, as with every release. Core adds the columns of an organization's provider to its table of Git providers at its start (an additive migration; the 1.6.0 core runs on the new schema).
• No values change. The chart passes core one new computed setting, what the doctor needs to know about the Git provider and registries egress rules, so run the 1.6.1 core with the 1.6.1 chart.
• Rolling back to 1.6.0 works, but a 1.6.0 core retires, at its start, every Git provider its values do not name, organizations' providers included. Their rows, secrets and the members' connections stay; when 1.6.1 starts again it brings back those a 1.6.0 core retired (not those an owner retired). While a 1.6.0 core runs, organizations' providers cannot be used.
• hart 1.6.0 keeps working against 1.6.1, but warns that the API's minor version differs. Update it from the release's files (Install hart) for hart org git-providers.

NewCopy Anchor Link

An organization's own Git provider. Until 1.6.0 only the installation's operator could add a Git provider, in the chart's values. From 1.6.1 on, an organization's owners register their own Gitea or Forgejo for the organization's teams, next to the installation's providers: in the console under Members › Organization › Git providers, or with hart org git-providers. A provider has an id, a name, an https:// URL, the OAuth2 application's client id and secret, and, for a provider behind a private CA, that CA. The console shows the redirect URI for the application while you type the id (https://<console>/auth/git/<id>-<suffix>/callback), so you can create the application at the provider before you save. The client secret and the CA are stored encrypted like your Git tokens and are never shown again, not in the API, not in the audit log. Owners can change the name, URL, client id, secret and CA, and retire a provider: that disconnects every member, and the workspaces lose access to its repositories while their files stay. Registering the same id again brings it back. See Bring your organization's Git provider.

Members connect as before. An organization's provider shows in Account settings › Git connections with the organization's name, and the members connect their own account to it there. Only the organization's teams use it: Create workspace and Git access offer it as <name> · <organization> to the organization's teams, and the Git proxy refuses its repositories for everyone else. hart ws create picks the provider for you when the team can use only one.

A guard on the provider's address. Harthelm refuses, with the reason (422 git-provider-url-refused), a URL that is not https:// or that points at this machine (localhost, loopback addresses), at a link-local address such as the cloud metadata service 169.254.169.254, at a name inside the cluster (*.svc, the cluster domain), at a name without a dot, or at a private IP address typed as numbers. A provider on your own network is registered by its DNS name; a name that resolves to a private address is allowed. When core connects, it resolves the name itself and never connects to loopback or link-local addresses, whatever the name resolved to. See Git providers › An organization's providers.

In the API (0.13.0). GET, POST /orgs/{org}/git-providers and GET, PATCH, DELETE /orgs/{org}/git-providers/{id} for owners of the organization (org.manage; 403 for other members, 404 for people outside the organization), see Register a Git provider for the organization. GET /git/providers and your Git connections carry org_id and org_name for an organization's provider. Every change is audited as git_provider.create, .update or .retire.

For operatorsCopy Anchor Link

• Egress. Core reaches an organization's provider through the chart's network policies like any other host. On a default installation, a provider at a public address on port 443 is reachable through networkPolicy.egress.registries; a provider on a private address or another port needs networkPolicy.egress.gitProvider to let it through, or a rule in networkPolicy.egress.extra. The doctor's network-policy check names the organizations' hosts that no rule lets through.
• No allow-list of hosts yet. In 1.6.1 any address that passes the guard above can be registered. An allow-list for the operator is planned.
• An egress proxy (global.proxy) decides for core's connections to an organization's provider; only the registration's checks apply. Put a provider core must reach directly into NO_PROXY.
• When running workspaces see a change. A new workspace gets the organization's providers at once. Adding or retiring one, or changing its URL, reaches the running workspaces of the organization's teams at core's next periodic reconcile of each, within 10 minutes, and follows workspaces.upgradePolicy.

Known limitsCopy Anchor Link

• Gitea and Forgejo only. GitHub as an organization's provider is not in this release.
• No "test connection". A wrong client id or secret shows when the first member connects.
• At most 20 active providers per organization.