Gating enforces governance policies by requiring approval before specific user actions can proceed. Gates help teams limit risk, automate compliance, and respond quickly to policy changes. Gating decisions are applied automatically and recorded for audit.
Governance Admins define gates in policies to control actions based on parameters such as hardware tiers or data planes. When a policy with gates is attached to a project, Domino evaluates any actions at creation and on restart. If a user attempts a gated action, they are blocked until the required approval is granted.
Common use cases include:
-
Blocking GPU or high-cost hardware tiers until reviews are complete
-
Controlling deployments to specific data planes
-
Rechecking approval status on restart to maintain compliance
Gates apply only to governed actions in projects where a bundle with gating policies has been attached.
Gates are defined in YAML as part of a governance policy. Each gate includes:
-
One or more rules that define the governed action and its parameters
-
A list of required approvals for the action to proceed
Example: Define gates in YAML
In this example, the gate blocks creation of apps that use the large-k8s or gpu-small-k8s hardware tiers unless the Validation sign off stage has been completed:
gates:
- name: Prod
rules:
- action: CreateApp
parameters:
hardwareTierId:
- large-k8s
- gpu-small-k8s
approvals:
- Validation sign offWhen a practitioner attaches a bundle with gating policies to a project, the system begins enforcing the gate rules. Only governed actions and parameters are affected. All other activity proceeds normally.
Gates remain active as long as the bundle is attached and the policy requires the relevant approvals.
Gates rely on the same approval stages used elsewhere in governance. Admins or approvers can grant or revoke approvals at any time.
When approval status changes, the system updates gate behavior automatically. This affects both new actions and restarts of governed resources.
When a user attempts a governed action, the system evaluates gate rules in real time. If the action and its parameters match a gated rule, the system checks for approval before allowing it to proceed.
-
During creation: invalid configuration options are blocked in the UI
-
On restart: users receive an error if a previously approved configuration no longer meets policy requirements
| Action | Result |
|---|---|
User creates an app using allowed settings | Action proceeds |
User selects a gated hardware tier without approval | Action is blocked |
Approval is granted after creation | Gated actions become allowed |
Approval is revoked after creation | Gated actions are blocked on restart |
Gating is enforced by two internal services:
-
Governance Service: manages policies, approvals, and gate definitions
-
Rules Service: applies gate logic and determines whether to allow or block actions in real time
Gate rules are stored in the shared governance database. When a policy is activated, the Rules Service sets all governed actions to "deny" by default. Actions are allowed only after the required approvals are granted.
All rule evaluations and gating outcomes are:
-
Recorded in the Audit Log
-
Tracked in MixPanel to support compliance reporting and usage analysis
-
Create governed bundles - get steps on creating and using our governed bundles.
-
Send governed bundles for review - submit your bundles for review and get them published.
-
Use Findings to track and manage issues throughout the governance lifecycle of a bundle.