v0.8.1

• Image: ghcr.io/hugr-lab/tresor-server:v0.8.1 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.8.1 - signed.

Nothing to migrate; no change in the service.

• tresor from DuckDB's community extensions: the docs install it with INSTALL tresor FROM community.
• tresor pinned at v0.1.1 (b2937ac) - what community serves; tresor's conformance suite on every state store at it.
• The docs are versioned (spec 035: the latest release at the root, /next/ for main, only the latest indexed) and on hugr-lab.com: https://hugr-lab.com/docs/tresor-server/.

v0.8.0

• Image: ghcr.io/hugr-lab/tresor-server:v0.8.0 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.8.0 - signed.

Nothing to migrate. One behaviour change, below.

New

• Snowflake: Iceberg through Horizon (spec 032) - DuckDB's iceberg reads Snowflake-managed Iceberg tables with vended credentials; the secret's token generated three ways, all checked live (Snowflake, DuckDB 2.0.0, tresor 0.1.0):
  • a PAT, as a service: oauth2_client_credentials takes a client_secret with no client_id;
  • a key pair, as a service: dynamic.identities kind snowflake (account, user, public_key_fp, an RSA key in a file, Key Vault, Transit, AWS KMS or Cloud KMS) - a jwt_assertion login sends Snowflake's JWT; a key file's fingerprint is checked at start;
  • each user's own: mint+exchange (Entra On-Behalf-Of) and Snowflake's External OAuth.
    An ATTACH holds Snowflake's token for its hour: a longer session attaches again.
• Docker (spec 033): deploy/docker - to try it (the service, Keycloak with a realm, sample secrets; nothing is a default password) and on one host (behind Caddy's HTTPS, SQLite or PostgreSQL).

Changed

• A client secret without a client id is sent in the form (every OAuth2 login flow): an oauth2_password or oauth2_refresh login with a client_secret and no client_id sent HTTP Basic with an empty user before.
• The console: the service view shows the protocol's capabilities (and token_exchange only with an exchange client); "Revoke my sessions on servers" works for administrators (it was refused, 422).
• The docs (spec 034): stale pages, missing settings and checks; the Terraform recipes default to this release; CRDs applied from the OCI chart.

v0.7.5

• Image: ghcr.io/hugr-lab/tresor-server:v0.7.5 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.7.5 - signed.

Nothing to migrate; nothing changes until set.

New (spec 031)

• A delegation actor by role: policy.actors accepts role:<name> with its issuer (one of issuers) - every service whose token from that issuer carries the role acts for users with the rule's verbs: one rule for every node group. A rule naming the client wins; a person with the role is no actor; a grant stops working once its node's token no longer carries the role. A role is broader than a client id - see Configuration.
• A delegation grant is presented by a service token of its own client (it was by the same identity).
• The console's service view shows an actor's issuer.

Console and docs

• The tresor mark in the console, its favicon and the docs site.
• The console's active sidebar item and link-buttons keep their light text on hover.

tresor-server v0.7.4

• Image: ghcr.io/hugr-lab/tresor-server:v0.7.4 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.7.4 - signed.

Nothing to migrate; nothing changes until set.

New (spec 030, with tresor spec 041)

• whoami names the person: an optional name - the first non-blank of preferred_username, name, email, upn - for people to read, never an identity (nothing granted, owned or audited by it). Under a delegation grant, the user's. The console shows it.
• An issuer's ignore_roles: glob patterns of roles never taken as principals - Keycloak's offline_access, uma_authorization, default-roles-*.
• tresor pinned at 594fcca: tresor v0.1.0 (protocol version 1, DuckDB v2.0.0) with its specs 040 (device-flow PKCE) and 041; conformance on every state store.

tresor-server v0.7.3

• Image: ghcr.io/hugr-lab/tresor-server:v0.7.3 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.7.3 - signed.

Nothing to migrate; the chart and the configuration are unchanged.

New (spec 029)

• The TLS certificate is read again when it changes (tls.cert, tls.key, every 30 s): a certificate renewed in place - cert-manager's Secret - is served without a restart. A new pair serves once it checks whole (the key the certificate's, in date); a bad one leaves the old pair serving, logs an error and makes readiness's tls check degraded.

tresor-server v0.7.2

• Image: ghcr.io/hugr-lab/tresor-server:v0.7.2 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.7.2 - signed.

Nothing to migrate: no column, no CRD change; nothing changes until set. See Upgrading to 0.7.2.

New

• state.auth: vault (spec 027): the state's database credentials from a Vault/OpenBao database secrets engine - a user and a password per lease, through the vault: connection (or a named source's); new credentials before a connection could outlive its lease. On PostgreSQL state.vault.set_role names the group role every lease's user is granted, which owns the tables. Proven in CI against OpenBao 2.4.1 and HashiCorp Vault 2.1.1. (A KV field through password_ref: ref+vault://… works as before.)
• configTemplate (spec 028, the chart): config rendered through tpl with the chart's context - an umbrella chart's global values in state.dsn, the issuers, policy.admins. Off by default; the render unchanged without it.

tresor-server v0.7.1

• Image: ghcr.io/hugr-lab/tresor-server:v0.7.1 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.7.1 - signed.

A security release: built with Go 1.27.3. The service is otherwise unchanged since v0.7.0 - no migration, no CRD or configuration change.

• govulncheck: no vulnerability the code reaches. One remains in a required module, GO-2026-5932 (golang.org/x/crypto/openpgp, unmaintained, no fix) - a package the service does not import.

tresor-server v0.7.0

• Image: ghcr.io/hugr-lab/tresor-server:v0.7.0 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.7.0 - signed.

Nothing to migrate: no column, no CRD change. See Upgrading to 0.7.

New (spec 026): an unattended install

• The cluster's own ServiceAccounts as callers: an issuer's ca_file (the cluster's CA) and discovery_token_file (the service's projected token, to read a Kubernetes API server's issuer discovery and keys). The token needs ca_file, and then only the cluster's CA is trusted: it never reaches a publicly certified host. An install Job logs in with its projected token and is an administrator by the service rule (client:system:serviceaccount:<ns>:<name>, or subject:<issuer>|... with several issuers).
• Chart: namespaceOverride puts every object in a namespace of its own (an umbrella chart installs the service beside others); clusterIssuer mounts the service's projected token and the cluster's CA.
• Proven on kind in CI: the release in one namespace, its objects in another, an install Job writing and granting a secret by its ServiceAccount token.

tresor-server v0.6.0

• Image: ghcr.io/hugr-lab/tresor-server:v0.6.0 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.6.0 - signed.

Nothing to migrate: no column, no CRD change. Roll out every replica before writing a generated variable. See Upgrading to 0.6.

New (spec 024, with tresor spec 037)

• Generated values in variables, as in secrets: mint+exchange://, mint+claim://, mint+login:// / mint+rule://, whole or ${…} - made on each read for the effective user (under a delegation grant the grant's user), served sensitive with an expires_at. A client puts them where DuckDB takes a string - a setting, a query. A login feeds a variable only when its scope names variable://<name> (or variable://).
• tresor pinned at fc97659 (specs 035-037): a variable's value with an expiry; a sandboxed DuckDB (enable_external_access = false) stops tresor's own requests - the docs say what to allow. DuckDB f8f3f4d (the v2.0 branch).

Changed

• A login's scope begins with the base URL it calls, then base URLs or variable://<name> only.
• A variable written before is served as written, but for its escapes (mint++, $${).

tresor-server v0.5.1

• Image: ghcr.io/hugr-lab/tresor-server:v0.5.1 (linux/amd64, linux/arm64, distroless, non-root) - signed, with an SBOM and provenance.
• Chart: oci://ghcr.io/hugr-lab/charts/tresor-server, version 0.5.1 - signed.

The service is unchanged since v0.5.0: no migration, no CRD change.

• tresor pinned at b4bd249 (its specs 031-033): DuckDB 7304f7b; a served secret built through its type's own deserializer - BigQuery's secret class works; tresor's CI checks that a served secret reaches httpfs, postgres_scanner and iceberg. Conformance runs on every state store at this pin.
• Docs (Generated parameters): BigQuery with external_account_json or a rule's access_token (never a service account's key); postgres's canonical keys (host, port, dbname, user, password); iceberg reads a ready token once at ATTACH; whose a database's secret is (whoever attaches it).