Every term hull uses, alphabetised, with links to the relevant guides.
Apply
The action of sending a rendered manifest to the Kubernetes API. Hull uses
server-side apply with field manager hull, so repeated invocations
against the same release manage the same fields without spurious conflicts.
hull apply --plan <file> executes a plan produced by hull plan; hull
install and hull upgrade apply directly. → Apply.
Audit trail
The chronological record of every install, upgrade, rollback, and uninstall
against a release: action, user, hostname, hull version, kubeconfig context,
CLI flags supplied, and value files referenced. hull audit <release> prints
it. → Audit.
Canary
A staged upgrade that steps a release through a series of replica counts (or
percentages) with a bake-and-verify pause at each step. `hull canary
--stages 1,3,5 --bake 60s` upgrades to 1 replica, waits, advances to 3,
and so on. Failure at any stage rolls back to the prior revision.
→ [Canary](/hull/cli/canary.html).
## Capabilities
The cluster-info namespace exposed to templates as
`${capabilities.kubeVersion.Version}`, `${capabilities.apiVersions}`, etc. Used
to gate version-specific Kubernetes fields. → [Capabilities](/hull/templates/capabilities.html).
## ConfigMap-backed storage
An alternative release-storage driver (`HULL_DRIVER=configmap`) for clusters
where Secret access is restricted by RBAC. It mirrors the Secret driver's
semantics, including the same 1 MiB size cap.
→ [Environment variables](/hull/cli/README.html#environment-variables).
## Controller
`hull controller` is the in-cluster reconciler that watches `HullRelease` CRs
and converges declared state — the Kubernetes-native deployment pattern for
hull packages, comparable to Flux's helm-controller for HelmRelease CRs.
→ [`hull controller`](/hull/cli/controller.html).
## Cosign
Sigstore's container-signing tool. Hull doesn't bundle cosign signing but works
with the standard workflow: `hull registry push` to OCI, `cosign sign` the
artifact, then `cosign verify` before `hull install`.
→ [Signing guide](/hull/guides/signing.html).
## Cross-release dependencies
Releases that depend on other releases being installed first, declared in
`hull-releases.yaml`. Distinct from layers (which compose into one release) and
workspace members (sibling releases from one repo).
→ [Cross-release dependencies](/hull/guides/releases.html).
## CRD (Custom Resource Definition)
Kubernetes' extensibility mechanism. Hull packages can ship CRDs in `crds/`
(applied first, hull waiting for `Established=true` before continuing) or in
`templates/` (sorted before other kinds in the install graph).
## Drift
Divergence between what hull recorded and the live cluster. Caused by `kubectl
edit`, other operators' reconcilers, manual patches, or webhook mutations.
`hull drift ./pkg` renders the package and reports, per field, where the
package, recorded state, and running cluster disagree. → [Drift](/hull/cli/drift.html).
## Dry run
A render that does not persist. `--dry-run client` renders locally without
contacting the cluster; `--dry-run server` submits to the API for admission
validation without applying. Available on install, upgrade, plan, apply.
→ [`hull install`](/hull/cli/install.html).
## Environment
A named deployment target (`dev`, `staging`, `prod`) declared inside `hull.yaml`
with its own value overrides. Selected with `--env `. Inheritance is
supported (`inherits:` chains one environment onto another; cycles are
rejected). → [Environments](/hull/guides/values.html#environments).
## Fingerprint
A PGP key's hex-encoded fingerprint, shown by `hull keyring list` to identify
keys uniquely.
## GitOps
A workflow where desired state lives in git and a reconciler converges actual
state to it. Hull integrates with Argo CD and Flux as a packaging/templating
tool that produces deterministic manifests they sync, or via `hull controller`
as the reconciler itself.
→ [Use cases — GitOps](/hull/use-cases.html#for-gitops-teams-argo-cd-flux).
## Hook
A Job- or Pod-shaped resource hull runs at a lifecycle point (`pre-install`,
`post-install`, `pre-upgrade`, `post-upgrade`, `pre-rollback`, `post-rollback`,
`pre-delete`, `post-delete`, `test`). Each revision's hooks are persisted with
the release, so rollback re-runs the hooks that revision originally shipped.
→ [Hooks guide](/hull/guides/hooks.html).
## Hull package
A directory with `hull.yaml`, `values.yaml`, and `templates/` (plus optional
`crds/`, `hooks/`, `tests/`, `files/`, `notes.yaml`, `profiles/`, `policies/`,
`README.md`, `LICENSE`, `hull.lock`). The unit hull packages, distributes,
installs, and tracks. → [Package anatomy](/hull/guides/packages.html).
## hull.lock
The lockfile that pins the resolved version, ref, and digest of every layer and
required package. Regenerated by `hull dependency update`. Commit it — without
it, two builds of the same package can resolve different layer versions under
the same constraint.
## hull.yaml
The package manifest at the root of every hull package. Declares `name`,
`version`, `apiVersion`, `layers`, `requires`, `environments`, `immutable`, and
metadata. → [`hull.yaml` reference](/hull/reference/hull-yaml.html).
## hull-releases.yaml
The manifest for cross-source release orchestration. Declares releases (each
with a package source — local, OCI, HTTPS, git) plus optional `dependsOn`.
Operated via `hull releases plan/install/upgrade/uninstall/status`.
→ [`hull-releases.yaml` reference](/hull/reference/hull-releases-yaml.html).
## hull-workspace.yaml
The manifest for multi-package orchestration in one repo. Declares members
(sibling packages) plus `dependsOn` and per-member overrides. Operated via
`hull workspace plan/install/upgrade/uninstall/diff/status`.
→ [`hull-workspace.yaml` reference](/hull/reference/hull-workspace-yaml.html).
## Immutable
A `hull.yaml` field (`immutable:`) listing resource identifiers a package marks
as immutable. It's a declarative annotation on the manifest and is accepted by
the package format; it is not enforced by any current command. To force through
immutable-field changes at apply time, use `hull upgrade --force` (delete and
recreate). → [`hull.yaml` reference](/hull/reference/hull-yaml.html).
## Install
Creating a new release in the cluster. `hull install ` renders, validates, applies, and stores.
→ [`hull install`](/hull/cli/install.html).
## Layer
Another hull package whose templates and values are merged into the current
package, producing a single rendered manifest belonging to one release.
Distinct from a workspace member (a separate release). → [Layers](/hull/guides/layers.html).
## managedBy=hull label
The canonical label hull applies to every resource it creates and every
namespace it provisions — the single source of truth for "did hull do this?".
One selector finds everything: `kubectl get all -A -l managedBy=hull`. The
legacy `owner=hull` label is also honoured.
## Manifest
The rendered YAML output of templating a hull package — what hull applies to
the cluster. Stored gzip+base64-encoded inside the release record so rollback
can re-apply exactly what was applied originally.
## OCI / OCI distribution
The container-image distribution spec, reused for non-image artifacts. Hull
packages push and pull as OCI artifacts. Version identifiers go in the tag:
`oci://host/path:1.2.3`. → [OCI guide](/hull/guides/oci.html).
## Partial
A named block in `_helpers.yaml` (or any `_*.yaml` file in `templates/`) that
other templates `${include}` into themselves — hull's reusability primitive
within a package. → [Partials](/hull/guides/packages.html#partials-and-includes).
## Plan
An apply-able JSON artifact of a hull operation: the rendered manifest plus a
SHA-256 integrity digest. `hull plan -o ` creates it; `hull apply --plan
` re-renders, verifies the digest, and applies. The digest detects any
change between planning and applying.
→ [`hull plan`](/hull/cli/plan.html), [`hull apply`](/hull/cli/apply.html).
## Plugin
An external command that extends hull's CLI. Discovered via `hull plugin list`,
installed via `hull plugin install `. → [`hull plugin`](/hull/cli/plugin.html).
## Policy
A rule evaluated against a rendered manifest. Packages carry declarative rules
in `policies/`. `hull policy check ` evaluates them; `hull policy list`
shows them. → [Policies](/hull/cli/policy.html).
## .prov file
A PGP cleartext-signed sidecar that travels alongside a `*.hull.tgz` archive.
It carries the package name, version, and SHA-256 digest, signed by the
publisher's key. `hull install --verify` and `hull pull --verify` validate it
against the local keyring.
## Profile
A named values overlay file in `profiles/.yaml`, activated by `--profile
` on the CLI or `profile:` on a workspace member or environment.
Orthogonal to environments. → [Profiles](/hull/guides/values.html#profiles).
## Provenance
The data proving where a release came from: the PGP signature on the source
archive, an optional cosign signature on the OCI artifact, and the audit data
hull records on each install. `hull get provenance ` also traces where
each merged value was resolved from. → [Audit](/hull/cli/audit.html),
[Signing guide](/hull/guides/signing.html).
## Reconcile
Re-applying a release's stored manifest to converge drifted fields.
`hull reconcile ` — addressed by release name, so it needs no package
source. → [`hull reconcile`](/hull/cli/reconcile.html).
## Release
A named instance of a hull package installed in a cluster, identified by
`name + namespace`. Every install/upgrade/rollback increments a revision
counter and stores a new release record. → [Secret-backed storage](#secret-backed-storage).
## Render
Templating a package's `templates/` (and `crds/`, `hooks/`, `notes.yaml`)
against merged values to produce a rendered manifest. `hull template `
does this offline, no cluster contact.
## Required package
A separate package the current one must be co-deployed with, declared in
`hull.yaml` under `requires:`. Distinct from `layers:` (which merge into the
same release) — each requirement stays its own release. Hull installs
requirements automatically; pass `--skip-requires` to skip them.
## Revision
A monotonically increasing integer per release. Each install/upgrade/rollback
creates a new revision. The current revision has `status=deployed`; older ones
are `superseded`. `hull history ` lists them.
## Secret-backed storage
The default release-storage driver. Each revision is a labelled Secret named
`hull.v1..v` in the install namespace. Switch with
`HULL_DRIVER=configmap|memory|sql`.
→ [Environment variables](/hull/cli/README.html#environment-variables).
## Server-side apply
Kubernetes' patch mode where the API server tracks per-field ownership by
`fieldManager`. Hull uses `fieldManager=hull`, so its own repeated applies
don't conflict, while an external operator's edits — owned by a different field
manager — surface as drift.
## Tag
In OCI distribution, a string label on an artifact (`1.2.3`, `latest`,
`stable`). Hull identifies package versions by tag: `oci://host/path:1.2.3`.
The version goes in the tag, not a separate `--version` flag.
## Topological order
The dependency-respecting order in which workspace members or cross-release
dependencies install, computed from `dependsOn`. Members in the same level have
no inter-dependencies and are eligible to run in parallel.
## Workspace
A `hull-workspace.yaml` plus a tree of member packages from one repo. Operated
as a unit via `hull workspace install/upgrade/uninstall/plan/diff/status`.
Members are separate releases installed in topological order.
→ [Workspaces](/hull/guides/workspaces.html).
## Where next
- [FAQ](/hull/faq.html) — common questions
- [Use cases](/hull/use-cases.html) — by role
- [Comparison with other tools](/hull/comparison.html)
- [Documentation map](../README.md#documentation-map)