CLI

This section covers the spec of every subcommand provided by the tazuna binary, one command per page.

The pages are designed to be read as a contract. For command choice and operational usage, see Guides; for what each command is solving in the first place, see Concepts.

Subcommand List

• tazuna init — generate an includes-based tazuna.yaml skeleton
• tazuna apply — apply tazuna.yaml to the cluster (writes state back)
• tazuna build — emit the rendering result without touching the cluster
• tazuna check — validate tazuna.yaml
• tazuna destroy — delete Tazuna-managed resources from the cluster
• tazuna plan — diff the Build result against the live cluster field by field
• tazuna status — show the readiness of managed resources recorded in State
• tazuna state list — list the resources recorded in State
• tazuna state diff — show the difference between the Build result and State
• tazuna state drift — detect drift between State and the live cluster
• tazuna secret-to-genesissecret — write existing Secrets to 1Password and GenesisSecret
• tazuna tags — list the tags written in tazuna.yaml
• tazuna version — output version information

Global Flags

Persistent flags inherited by every subcommand.

Common Behavior

kubeconfig

Subcommands that access the cluster load kubeconfig at startup and operate against the cluster pointed to by current-context. Tazuna does not provide its own KUBECONFIG environment variable or --kubeconfig equivalent flag; it follows the same resolution rules as kubectl.

Evaluating context_matches

When spec.context_matches is set in tazuna.yaml, the current-context name is matched against it immediately before touching the cluster.

• Commands where evaluation runs: apply / destroy
• Commands where evaluation does not run: build / check / plan / status / state list / state diff / state drift / tags / version / secret-to-genesissecret

The evaluation mode follows spec.context_match_mode (or / and, default or). See tazuna.yaml schema - context_matches for details.

Validating tazuna.yaml

apply / build / destroy / check / tags all load and validate tazuna.yaml at the very start of execution. On validation failure, no cluster access happens. For the list of check items, see tazuna.yaml schema - Validation summary.

In addition, on every command that loads tazuna.yaml (including plan / status / state list / state diff / state drift on top of the above), spec.minimumSupportedTazunaVersion is compared against the running tazuna’s version at load time. If the running version is below it, the command exits with an error immediately. See tazuna.yaml schema - minimumSupportedTazunaVersion for details.

Exit Codes

Non-zero exit can be treated as failure as-is by CI. There is currently no distinction in exit code per command.

Environment Variables

In addition to CLI flags, here is the list of environment variables Tazuna consults.

The old TAZUNA_STATE_SYNC_DELETE environment variable has been removed along with tazuna state sync. To delete resources in the removed category, use tazuna apply --sync --prune.