Skip to content

Operate

These pages apply to every install, with one product or several. Each product’s install page covers the short path. Come here for the details.

Every install runs the same core: a gateway that serves everything from one address, the sign-in service, and the PostgreSQL and Redis the products keep their data in. The products you choose run behind the gateway.

veltro is the operator entry point for all of it. The Make targets in a clone are thin wrappers over python3 -m veltro_cli, so the two can’t drift.

VectorFlow and Sigmatic can each run without the other product or Warden. Both still depend on Veltro core: identity and the gateway, with the selected product’s datastores and workers. Choosing fewer products doesn’t create an independent release; installs still use one suite version and its pinned manifest.

Core keeps one authority implementation for request assertions, PATs, grants, teams, workload exchange and approval policy. Home and settings aggregation stay. This milestone adds no mandatory cross-product responsibilities and doesn’t extract identity or add a second login path.

After Warden’s release removing fork_to_lake, release operators hold it at that published version with the release-suite.yml dispatch input hold: warden=X.Y.Z. Replace X.Y.Z with the published version on every cut; an empty hold selects the newest published product releases. Advance Warden only for a security, data-loss or existing-response correctness fix.

Warden’s cases, approvals, approval expiry and reversal of due active effects keep running. Existing Sigmatic escalation and writeback remain supported when Warden is installed; Sigmatic also handles its absence. No new Warden vendor integration is required to release VectorFlow or Sigmatic.