Changelog

What changed, release by release.

Vennir is 0.x: releases come often, and only the latest gets security fixes. Each release attaches the two Helm charts and vennir for Linux and macOS, with checksums.

All releases on GitHub On main, not yet released
Unreleasedon main since v0.11.0

Coming in the next release.

Merged, tested and on main, but not in a tagged release yet. Build from main to try it, or wait for the tag.

  • Guides for getting going

    • Onboarding, from installing Vennir to a first deploy, and where to host it: kind, GKE, EKS or your own cluster.
    • Deploying to Google Cloud and to AWS from Vennir: every step a team takes so its products can make resources there.

  • The API gateway and the network

    • The API gateway, start to finish: turning it on, publishing a backend, calling it, and putting it on the internet.
    • Addresses and firewall rules: which address each part uses, how to find it, and when a fixed outbound address is worth it.
Releases

Newest first.

v0.11.0

Latest

Vertra is now Vennir

  • A new name, everywhere. The CLI is vennir, catalog files say vennir.dev/v2, team namespaces carry vennir/team and the platform runs in vennir-system. Images and charts are published under ghcr.io/rburns629/vennir; releases through 0.10.0 stay under the old name.
  • A clean break. A Vennir console doesn't read a Vertra catalog release: publish the catalog again with vennir, which moves a catalog repository's wrapper and files over to the new names.

v0.10.0

Values a team's builds need

  • Build environments per team. A catalog can give a team's image builds values of their own, from a GitHub Environment only main may use. Each such team's builds run in a job of their own; pull requests only validate them.
  • Publishing's credentials stay out. The signing key and registry password are refused if they would reach a team's build.

v0.9.0

The security review's findings, fixed

  • Who may do what, tightened. A bot belongs to the one team that made it; products are registered by the catalog or an admin, never a team's maintainers; a catalog release registers products only in the teams it names; single sign-on linking an account makes it the only way in.
  • The gateway checks callers as the console does, forwards only what an API's OpenAPI document declares, and lets an API use an in-cluster backend only in its own team's namespace.
  • The cluster holds more. A step's container is held to what the executor builds; the console may run only its scans and verifications as Jobs; the kernel signs in to Postgres as a role of its own.
  • Releases you can trust. A catalog release pins each product to the signed image of its own commit; every chart vennir installs is checked by its SHA-256 first; the release scans what it pushes and can't half-publish a version.
  • Limits. Each person may ask the chat agent 30 questions an hour and 200 a day; bots none.

v0.8.0

Clouds per product, and dispatch that doesn't wait

  • A product says which clouds' installs it's for, and the samples say theirs.
  • A scheduler pass records what finished, and commits it, before it dispatches; the signature check looks at a step's Pod, not its Job, so dispatch never waits on it.
  • Image sources say where they don't apply: an added source doesn't run where signed images are required.

v0.7.0

What the billed run found

  • Proven on a real cloud. Benchmarks on a GKE cluster, and fixes from the paid proof run: apply's approval screen, the gateway's problems, who may call an API, and a refused SecretStore.
  • A generated admin password is saved to a file, never printed.
  • Observe's alerts on GKE's managed Prometheus, and an alert for steps with no node to run on.
  • The gcp samples retry safely: they write a result when signing in fails, and wait on a build an earlier attempt left running.

v0.6.0

The redesigned console

  • Every page redesigned: Home, Catalog, Cart, Compose, Runs, Teams, APIs, Observe and Admin, with a guide linked from each page, the Ask panel, and a resizable, collapsible sidebar.
  • Ask Vennir about a failed run, from its failure card.
  • Monitoring three ways: the cluster's Prometheus operator, a managed service (GKE's or Amazon's), or one bundled in the console chart, with the install's alerts on Observe.
  • Cross-cloud catalogs. An install reads another's catalog across accounts and clouds; vennir catalog grant gives exactly one reader access, and --revoke undoes it.
  • Managed databases: Cloud SQL on GCP and RDS on AWS, each service signing in as its own identity, with no passwords of Vennir's.
  • Per-team usage, on Observe's Usage tab and the Teams page.
  • The vennir CLI: backup, backups and restore; logs for the platform or one run's steps; upgrade advice; help and man pages for every command.

v0.5.2

Ordering from outside, the cart, and Ask

  • Ordering bots and order callbacks. A storefront may run only the templates listed for it, at a rate it can't exceed (429 with Retry-After), and hears each outcome as signed JSON. A team can have its runs' outcomes posted the same way.
  • The cart. Add actions from the Catalog and Vennir wires them by type, offers what's already deployed, and suggests what's optional. Teams define their own wiring types in the catalog.
  • Ask, the chat agent. On every page, answering only about Vennir from the docs it ships with, citations checked. Claude through Anthropic's API or Amazon Bedrock, or Gemini on Vertex AI; admins pick the model.
  • What a run made, and what depends on it. Each resource says what it provides and needs; deleting something another resource uses waits for an admin.
  • Hardening. TLS inside the cluster from each chart's own CA; the gateway signs in as its own database role and checks sessions with the console's public key; sign-ins audited; sign-out ends the session; bot tokens expire; a named image USER refused at once (IMAGE_USER_NOT_ALLOWED); NetworkPolicies enforced on EKS with no metadata server for steps.
  • Docs in the console, every guide searchable, in categories with a path through them.
  • A performance baseline: phase 1 benchmarks, and the scheduler's per-step database work batched.

v0.5.1

Approved base images

  • Approved base images, mirrored into the catalog's own registry, so products build on bases the catalog vouches for.
  • A team's page says who owns it in the catalog.

v0.5.0

Caps, capacity, SBOMs and alerts

  • Per-product limits. product.yaml's maxRunning caps how many steps of a product run at once, and a product chooses its capacity: spot or onDemand.
  • SBOMs. Catalog CI attests each image's software bill of materials, offered in Observe.
  • SecretStores on AWS, set up by vennir, each store's cloud identity belonging to one team alone.
  • Admin alerts on refused steps and platform changes, in a chat channel.
  • A step's timeout now counts from its container's start, not from when it was created.

v0.4.0

Catalog versions

  • Catalog versions, made by a Git tag in the catalog repository from what main already published, nothing rebuilt. An install follows one version, or the newest.
  • Reading another install's catalog enforces the owner's signer.
  • One owner per catalog repository.

v0.3.2

Signing proven on EKS

  • AWS KMS catalog signing works: vennir reads the key's public half as JSON, and signing is proven on EKS.
  • Catalog signing set up by vennir, proven on GKE.

v0.3.1

Keyless signing with cosign 3

  • Keyless catalog signing works with cosign 3, and policy-controller upgrades go through.
  • The catalog template pins vennir 0.3.0 and is checked with its pin.

v0.3.0

Signing, single sign-on, and a new console

  • Catalog signing with a KMS key or keyless, set up by vennir.
  • Single sign-on set up by admins, required per team, with groups mapped to teams (Google Workspace groups read by the console as itself).
  • Per-team resource limits, enforced by the cluster.
  • A hash-chained audit log, copied to write-once storage.
  • Automation: keyless bots signing in with a CI job's own identity, schedules on a cron as one of a team's bots, and notifications in the console, on chat webhooks and by email.
  • Before a run: readiness per install from products' check actions, and previews from their plan actions. After it: what a run made, kept past the run and deletable later.
  • The console redesigned: Runs, the run timeline, Catalog, Compose, Team, Admin and Observe pages, run forms made from schemas, and an image scans page.
  • HTTPS for the console from the chart, non-root required for the kernel and console Pods, and cleanup for the gcp and aws samples. Dependency updates across every project.

v0.2.1

Tag on GitHub Compare with v0.2.0 A tag without release notes.

Image scan fix

  • Go 1.27.3 and x/net 0.60.0, so the release's image scan passes.

v0.2.0

Tag on GitHub History to v0.2.0 A tag without release notes.

The first tagged release

  • The kernel in Go, with kernel-api and the console's API on Connect. The Python kernel and the REST API are gone.
  • One command line. vennir installs the platform and runs the catalog tool too (vennir catalog validate, check, publish, release and more), and the project took its name, Vennir.
  • vennir releases for Linux and macOS (amd64 and arm64), signed; a catalog's ./vennir wrapper downloads a pinned one by its SHA-256.

Before v0.2.0 there were no tagged releases. The full history is in the commit log.