Glossary

This glossary defines every key term used in GitOpsHQ documentation, UI, and API. Terms are grouped alphabetically. Use your browser's search (Ctrl/Cmd+F) to quickly find a term.

---

A

Agent A lightweight Go process deployed as a single-replica Kubernetes Deployment inside your cluster. The agent initiates an outbound gRPC connection to the GitOpsHQ hub and provides inventory reporting, ArgoCD status monitoring, resource inspection, log streaming, and command execution. No inbound ports need to be opened on the cluster.

Approval Policy A configurable rule that requires one or more designated approvers to explicitly approve an operation before it executes. Approval policies can be applied to releases, environment promotions, and sensitive cluster commands. Available on the Enterprise tier.

Artifact A versioned, immutable package stored in the organization's registry. Artifacts come in three types: Helm charts (tgz archives with Chart.yaml), Kustomize bases (directory structures with kustomization.yaml), and manifest bundles (collections of raw Kubernetes YAML files). Each artifact has one or more versions.

Audit Log An immutable, append-only record of every significant action taken within an organization. Audit entries capture the actor, action, resource, timestamp, and metadata. Audit logs are queryable in the UI and exportable on Enterprise plans.

---

B

Binding A declarative association between a reusable artifact (workload, Kustomize base, or manifest bundle) and one or more tenant-environment pairs. Bindings determine what gets deployed where. See also: Kustomize Binding, Manifest Binding, Scaffold.

Break-Glass Session A time-limited emergency access session that bypasses normal approval workflows and governance policies. Break-glass sessions are fully audited, require a justification reason, and automatically expire after a configurable duration. Available on the Enterprise tier.

Bulk Update An operation that applies the same change (typically an image tag update) across multiple tenants and environments in a single atomic commit. Bulk updates can be triggered from the UI or via the image-update webhook.

---

C

Cluster A registered Kubernetes cluster with an active agent connection to GitOpsHQ. Each cluster has a unique name within the organization, a provider label (AWS, GCP, Azure, on-prem, other), a region, and a connectivity status derived from the agent heartbeat.

Cluster Target A cluster that has been designated to receive delivery output for a specific project environment. When the delivery generator produces manifests for an environment, those manifests are directed to the environment's cluster target.

Command An operational action dispatched from the GitOpsHQ hub to a cluster agent. Supported commands include:

Commands may require approval depending on configured approval policies.

---

D

Delivery Generator The core engine inside GitOpsHQ that resolves all bindings, merges HQ variables, applies overlays, and produces final rendered Kubernetes manifests for every tenant-environment-service combination. The generator runs whenever a relevant change is committed to the hosted Git repository.

Drift The difference between the desired state (as defined in Git) and the actual state (as observed in the cluster). Drift can occur due to manual kubectl changes, external controllers, resource limits, or failed syncs. GitOpsHQ surfaces drift at the project, cluster, and tenant-environment levels.

---

E

Environment An ordered stage in the deployment pipeline representing a logical deployment target. Common examples: dev, staging, production. Environments are defined at the organization level (Org Environments) and inherited by projects (Project Environments). Each project environment maps to a cluster target.

Environment Compare A UI feature that provides side-by-side comparison of Helm values, image tags, and configurations across any two environments within a project. Useful for verifying what will change before a promotion.

Environment Freeze A state applied to an environment that blocks all deployments. Freezes can be scheduled (e.g., during maintenance windows) or manually activated. Available on Pro and Enterprise tiers.

---

F

Fleet Health An aggregate metric displayed on the dashboard showing the connectivity status of all registered clusters. A healthy fleet means all agents are connected and reporting heartbeats within the expected interval.

Freeze See: Environment Freeze.

---

G

Governance The set of policies, approval workflows, and access controls that ensure deployments follow organizational rules. Governance features include approval policies, environment freezes, break-glass sessions, and audit logging.

Grant A fine-grained permission assignment that gives a user, team, or service account access to a specific resource with a specific preset. For example, granting the "DevOps" team project.operator on "Project Alpha" allows that team to manage releases within that project. Allow grants are additive, but explicit deny actions take precedence in effective permission resolution.

---

H

Hosted Repository A Git repository managed by GitOpsHQ for each project. The hosted repository stores all delivery configuration: workload values, overlays, generated manifests, and release metadata. It serves as the single source of truth that ArgoCD or Flux watches.

HQ Variable A key-value pair used in Helm values templating. HQ Variables support hierarchical scoping:

A variable defined at a narrower scope overrides the same key at a broader scope.

---

K

Kustomize Base An organization-level reusable Kustomize configuration stored in the registry. A Kustomize base contains a kustomization.yaml and supporting files (patches, resources, generators). Bases are versioned and referenced by Kustomize bindings within projects.

Kustomize Binding An association of a Kustomize base with one or more tenant-environment pairs within a project. Each binding can include per-tenant-environment overlays that customize the base for specific deployment targets. The delivery generator merges the base with overlays to produce final Kustomize output.

---

M

Manifest Bundle An organization-level collection of raw Kubernetes YAML manifests stored in the registry. Unlike Helm charts, manifest bundles have no templating — they are applied as-is or with overlays. Bundles are versioned and referenced by manifest bindings.

Manifest Binding An association of a manifest bundle with one or more tenant-environment pairs within a project. Similar to Kustomize bindings, manifest bindings support per-tenant-environment overlays for customization.

---

O

OCI Credential Encrypted credentials for accessing external OCI (Open Container Initiative) registries. Used when pulling Helm charts stored in OCI-compatible registries (e.g., GitHub Container Registry, AWS ECR, Docker Hub). Available on Pro and Enterprise tiers.

Org Environment An environment definition at the organization level. Org environments establish the ordered stages (e.g., dev → staging → production) that all projects within the organization inherit. The order determines the promotion sequence.

Org Tenant A business tenant definition at the organization level. Org tenants represent your customers, regions, or deployment targets. They exist in a central registry and can be linked to multiple projects, creating project tenants.

Overlay A per-tenant-environment customization layer applied on top of a Kustomize base or manifest bundle. Overlays allow you to modify a shared base for specific deployment targets without forking the base itself. Overlays are stored in the project's hosted Git repository.

---

P

Pipeline An ordered sequence of promotion stages that defines how changes move through environments. A typical pipeline: dev → staging → production. Each transition can have configurable conditions (automatic, manual approval, or policy-gated). Available on Pro and Enterprise tiers.

Preset A named permission template that defines a set of allowed actions on a resource type. Presets simplify RBAC by providing human-readable permission bundles.

Project The primary delivery unit in GitOpsHQ. A project contains environments, tenants, workloads, bindings, releases, HQ variables, and a hosted Git repository. Projects are scoped to an organization and represent a logical application or service group.

Promotion The controlled movement of a release or configuration change from one environment to the next in the pipeline order. Promotions can be automatic (on successful sync in the source environment) or manual (requiring explicit approval).

---

R

Registry The central catalog within an organization that stores reusable Helm charts, Kustomize bases, and manifest bundles. The registry provides versioning, metadata, and a searchable inventory of all available artifacts.

Release A versioned change set that collects one or more pending configuration changes and moves them through an approval → deploy workflow. Releases provide atomic change management — either all changes in a release are deployed or none are.

Rollback Reverting a deployment to a previous known-good state. GitOpsHQ supports two types:

• Full rollback: Reverts an ArgoCD application to a specific previous revision
• Selective rollback (Enterprise): Reverts only specific services or tenants within a release

---

S

Scaffold The binding assignment matrix that shows which workloads, Kustomize bases, and manifest bundles are assigned to which tenant-environment pairs within a project. The scaffold provides a visual overview of the project's delivery topology.

Service Account A machine identity within an organization for CI/CD automation. Service accounts have tokens (prefixed ghqs_) with configurable scopes and allowed action patterns. Unlike user accounts, service accounts do not have passwords or interactive login capability.

Service Deployment A per-tenant-per-environment instance of a workload. Each service deployment has its own Helm values, image tags, replica configuration, and deployment status. Service deployments are the leaf nodes of the delivery hierarchy.

---

T

Team A named group of organization members. Teams simplify permission management by allowing grants to be assigned to a group rather than individual users. When a user is added to a team, they inherit all of the team's grants.

Tenant A business customer, region, or deployment target within a project. Tenants are linked from the org tenant registry and receive per-environment service deployments with customized configurations. See also: Org Tenant, Project Tenant.

---

V

Values Helm values configuration applied to a workload's service deployment. Values follow a merge hierarchy: chart defaults → workload defaults → environment values → tenant-environment values. Each layer overrides the previous one for matching keys.

---

W

Webhook An HTTP callback mechanism. GitOpsHQ supports:

• Inbound webhooks: Receive events from external systems (CI pipelines, ArgoCD) to trigger actions in GitOpsHQ
• Outbound webhooks: Send notifications to external systems (Slack, Discord, Teams, HTTP endpoints) when events occur in GitOpsHQ

Both types use HMAC signature verification for security.

Workload A Helm chart-based service definition within a project. A workload references an org chart (and version), defines default Helm values, and serves as the template for service deployments across tenant-environment pairs.

---

Related Pages

• Core Architecture — Understand the overall system design
• Dashboard — See these concepts in action
• Tenant Management — Deep dive into tenant concepts