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 apply — apply tazuna.yaml to the cluster
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 state list — list the resources recorded in State
tazuna state diff — show the difference between the Build result and State
tazuna state sync — reflect the differences State-first
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.

Flag	Alias	Type	Default	Description
`--file-path`	`-f`	string	`tazuna.yaml`	Path to `tazuna.yaml`.
`--log-level`	`-l`	string	`info`	Log level. One of `debug` / `info` / `warn` / `error`.
`--version`	-	-	-	A flag set only on the root command. Prints version info and exits. Equivalent to `tazuna version`.

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 / state list / state diff / state sync / 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.

Exit Codes

Exit Codes	Meaning
`0`	Success
Non-zero	Failure. An error in the form `error: ...` is printed to stderr.

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.

Environment Variables	Value	Affected commands	Effect
`TAZUNA_DESTROY_EXECUTABLE`	`true`	`destroy`	Unless this is set to `true`, `destroy` does not actually delete anything. Even if you say Yes at the prompt, nothing happens without this environment variable.
`TAZUNA_STATE_SYNC_DELETE`	`true`	`state sync`	Only when this is `true`, resources that remain in State but no longer exist in the cluster (removed) are deleted. The default is to skip deletion.
`KUBECONFIG`	Path	All cluster-touching commands	Follows the same kubeconfig resolution rules as ordinary kubectl.

Keyboard shortcuts

Tazuna