Gates

ConfigHub supports a number of gates, which block particular kinds of actions or operations: Apply Gates, Destroy Gates, and Delete Gates. It also supports non-blocking Apply Warnings.

Apply Gates are set by ConfigHub automatically when validating triggers do not pass on the most recent configuration data revision for a unit. They block apply operations at that revision until the underlying issue causing the validation failure is addressed, and/or another revision without apply gates is applied.

Apply Warnings work similarly to Apply Gates but are non-blocking. They are produced by validating triggers that have Warn set to true. When a trigger's validating function fails and the trigger is in warn mode, the failure is recorded as an Apply Warning rather than an Apply Gate. Apply Warnings are visible in the UI and CLI but do not prevent Apply operations. This is useful for advisory policies, soft constraints, or gradual policy rollouts where you want to surface issues without blocking deployments.

Both Apply Gates and Apply Warnings use a 3-part name format: <space-slug>/<trigger-slug>/<function-name>, which uniquely identifies the trigger that produced the gate or warning. Detailed validation results (failure messages and details) are also stored alongside gates and warnings. Triggers can include a Description field that explains what the trigger checks and how to fix failures; this is shown in the UI when hovering over a gate.

A special temporary gate, awaiting/triggers, is set when configuration data changes or when a unit is approved. It indicates that triggers have been enqueued for asynchronous evaluation and is automatically removed when all triggers complete. Many CLI commands support --wait to poll until this gate clears.

Apply Gates can also be produced when a Bridge Worker is disconnected and unable to execute a trigger's function. In this case, validating and mutating triggers for the unavailable worker produce gates, reflecting that the operation could not be performed. See the validation and policies guide for details on worker disconnection behavior and the FailOpenAfter field.

Destroy Gates are metadata properties that can be explicitly set on units. The string associated with a Destroy Gate is intended to convey the reason that destroy actions are blocked and/or the stakeholder or component blocking destroy actions. Currently anyone with permission to edit an entity may add or remove any destroy gates.

Delete Gates are metadata properties that can be set explicitly on any entity in ConfigHub. The string associated with a Delete Gate is intended to convey the reason that delete operations are blocked and/or the stakeholder or component blocking the deletion. Currently anyone with permission to edit an entity may add or remove any delete gates.

Note that blocking deletion on an entity residing in a space does not currently block recursive deletion of a space and everything within it, based on the principle that tenants within a space should not necessarily have the power to control the fate of the whole space. To protect entities within a space, place a Delete Gate on the space as well.