Short answers. Each links on to the page or guide with the rest: the product tour, the security model, getting started and every guide.
Vennir is an open-source platform, under the MIT License, that runs DAGs of containerized steps as Kubernetes Jobs. Each step is a product that a platform team published and reviewed, and it runs as its own identity with only its own team's secrets, handing its outputs to the next step. Other teams order those products from a catalog in a web console, through an API, or from their CI.
Organizations where platform teams own pieces of automation, such as creating a cloud project, a database or a deployment, and other teams need to use them. The platform team publishes each one as a product with its own identity and limits; other teams run it, or chain several together, without ever holding the credentials it uses.
In CI, a pipeline usually holds the credentials for everything it touches. In Vennir, credentials stay with the product that needs them: a step runs as that product's own Kubernetes ServiceAccount, in its team's namespace, from an image pinned to its digest and scanned, and the cluster's admission policies refuse anything else. Teams that only order a product never see its secrets.
Both run DAGs of container steps on Kubernetes, and Argo Workflows is the more mature and more general engine. In Argo, a workflow names its own images and settings, so whoever submits it decides what runs and what it may use. Vennir is built for many teams sharing automation: each step is a product another team published and reviewed, it runs as that product's own identity with only its team's secrets, and Kubernetes admission policies refuse anything else. If one team runs its own pipelines, Argo Workflows may be the better fit.
Backstage is a developer portal: a catalog of your organization's software, its docs, and software templates whose actions run inside the Backstage backend. Vennir is an execution platform: each step runs as its own Kubernetes Job, with its product's own identity and its team's secrets only, and Vennir's console is the place to order and follow those runs. They can work together, with Backstage as the portal and Vennir running the steps.
HCP Terraform runs Terraform: plans, applies and state for infrastructure as code, workspace by workspace. Vennir runs any container as a step, which can include Terraform or OpenTofu, and chains steps that different teams own, passing one step's outputs to the next. If everything you automate is Terraform, HCP Terraform is the more direct fit.
Where the cloud supports it, no. A step reaches Google Cloud through GKE Workload Identity and AWS through EKS Pod Identity, and can get an hour's token for federating with another cloud, so no long-lived key exists. When a target does need a secret, the team registers it: it lives in a Kubernetes Secret in that team's namespace, or is synced there from the team's own vault, and Vennir's databases keep only its name.
No. A step runs in its own team's namespace, where only Secrets that team registered can be mounted, and only by that team's reviewed products. Each step gets only the secrets it lists, as read-only files. The console checks this, and Kubernetes admission policies check it again on every Job, so going around the console doesn't help.
On any Kubernetes cluster at version 1.30 or later with a network plugin that enforces NetworkPolicy. The vennir CLI installs it on kind on your laptop, on a new GKE or EKS cluster, or on a cluster you already have; you can also install its two Helm charts yourself, with Helm 4.
Vennir is free and open source under the MIT License. You pay for what it runs on: your cluster, and the cloud resources your products create. On GKE or EKS, vennir apply shows an estimated monthly cost from your cloud's own price list before it creates anything.
Not yet. Vennir is at version 0.x: releases come often, and only the latest gets security fixes. The security model lists what isn't enforced yet; read it before trusting Vennir with production.
A container image and a product.yaml contract, kept in a team's catalog repository. product.yaml declares the product's actions, each action's input and output as JSON Schema, the ServiceAccount it runs as, which teams may run it, whether a run waits for a maintainer's approval, and what its error codes mean. Catalog CI builds, tests, scans and signs the image before it's released.
From the console's Catalog, with a form built from the action's schema; several actions at once with the cart, which wires each output to the input that needs it; templates that chain actions behind one form; the API; schedules; and bots, including CI jobs that sign in with their own OIDC identity instead of a stored token.
The run's page shows why, with the product owner's explanation of its error code and whether a retry is safe. A step is retried automatically only when its failure is retryable and its product allows more than one attempt, which only idempotent actions may. Anyone allowed to can also retry the step by hand, or run the whole thing again.
Only if you turn it on. Ask Vennir is an optional chat agent that answers questions about Vennir from its docs, with citations, and can propose a cart that you then place yourself. It stays off until an admin chooses a model: Gemini on Vertex AI, Claude through Amazon Bedrock or Anthropic's API, or an OpenAI-compatible server.
Clone the repository and run make quickstart. It builds a kind cluster with a local registry, installs Vennir with the same admission policies a cloud install gets, and serves the console on http://localhost:18080. Or, with the vennir CLI: vennir init dev --target kind, then vennir apply dev.