The whole platform, one part at a time.

A product is a folder: a Dockerfile, its tests, and one product.yaml.

Each team keeps its products in a catalog repository. The product.yaml says what the container's actions take and return, who may use them, how hard they may be pushed, and what to tell people when they fail. CI checks it, builds and scans the image, and publishes one signed release that every install pulls.

apiVersion: vennir.dev/v2
kind: Product
name: ticket
team: local
check: check            # is it ready on this install?
maxRunning: 2          # at most two of its steps at once
errors:
  MISSING_INPUT:
    means: It wasn't given what it needs.
    do: Fill in the missing input and run it again.
actions:
  - name: open
    idempotent: true     # the same title, the same ticket
    maxAttempts: 2
    shareWith: ["*"]
    cleanup: {action: close}
    plan: plan           # for Preview
    input:
      required: [title]
      properties:
        title: {type: string, maxLength: 200}
    output:
      properties:
        ticket:
          type: string
          x-vennir-provides: local.ticket

• Actions with schemas

  Each action's input and output are JSON Schema, enforced at submit, before the step starts and when it finishes. The run form is built from the same schema.

  INPUT_INVALID · OUTPUT_INVALID

• Readiness checks

  A check action asks the cloud who the product is and whether it may do its job, changing nothing. Each install runs it on registration, on a new image, daily, and on Check now.

  ready · principal · missing

• Errors explained by their owners

  A product says what each of its codes means and what to do; team.yaml says where to ask. The failed step shows both, and whether a retry is safe.

  errors · help · idempotent

• Capacity

  Cap a product's steps per install, keep two runs off the same project, choose Spot or on-demand nodes where the install offers both, and size each step.

  maxRunning · concurrencyKey · capacity · resources

• Approvals

  A step can wait for a maintainer of the product's team: always, only when another team runs it, or for named teams. Whoever started the run can never approve it.

  APPROVAL_DECLINED · APPROVAL_EXPIRED

• Sharing and targets

  shareWith names the teams that may run an action; visibility: hidden keeps it to yours. team.yaml lists which projects or accounts each team may aim your identity at.

  TARGET_NOT_ALLOWED

Products type their inputs and outputs (a project, a region, a database), so the cart can work out which step feeds which, what you already have, and what to ask once. Each step is still checked as if you ran it alone: a cart never lets you do more than you could step by step.

• Catalog and run forms

  Every template and action, with its readiness. Run opens a form from its schema; targets offer only what the owning team allows yours.

• Schedules

  A template or action on a timetable, as one of the team's bots, at most every five minutes, in your time zone.

• The API

  Connect services under /api: submit a DAG, run a template, place a cart. A repeated requestId returns the run already started.

• Keyless bots

  A GitHub Actions or GitLab job exchanges its own ID token for an hour as a bot, from one repository and, if you like, one branch.

• Ordering bots

  For a storefront: it may run only the templates you list, 60 orders a minute by default, under your team's quota and approvals.

• Callbacks and webhooks

  Signed posts when an order or a run finishes, to hosts your install allows. Chat notifications to Slack, Google Chat or Teams.

One page with five tabs: Security checks, Metrics, Usage, Logs and the Audit log. Everyone can open it; what each person sees follows what they may see elsewhere.

A console for the people who order. A CLI for the people who run it.

The console is the one front door: Catalog, Runs, What runs made, APIs, Observe, your teams, and Admin, each page linking the guide that explains it. vennir installs it on kind, Google Cloud, AWS or a cluster you have, and keeps each environment as one folder of settings, never a secret.

• init · applyAsk the questions; show what it will create and cost, and do it on approval
• check · statusTools, sign-in, cluster and what's installed, changing nothing
• sleep · wakeScale to zero, keeping the data; or on a schedule, or when idle
• backup · backups · restoreBoth databases as one pair, to the bucket or a folder; restore asks first
• logs · consoleThe platform's logs or one run's steps; port-forward the console
• config · tools · ssoChange a setting, fetch pinned tools, turn on Google sign-in
• catalog create · grantMake a catalog; let another install read it, keyless
• catalog validate · checkSchemas; then build, test with no network, and scan
• catalog publish · release · promotePush pinned, signed images; push the signed release; version it
• destroyRemove what it made, asking about each kind of data first

# change a setting, then make the install match it
$ vennir config set -e dev size resilient
$ vennir apply dev --plan-only

# before an upgrade
$ vennir backup dev --to ~/vennir-dumps
$ vennir config set -e dev vennir [VERSION]
$ vennir apply dev

# one run's steps, while their Pods are there
$ vennir logs dev --execution 3f2c9a7e-0b1d-4a51-9c6e-2d8f4b7a1e05

# the evening
$ vennir sleep dev
$ vennir config set -e dev scaleDown.schedule "0 20 * * 1-5"

# in your catalog repository, what CI runs
$ ./vennir catalog check teams/web/products/site
$ ./vennir catalog publish teams/web/products/site && ./vennir catalog release