Deployments and Promotion
A deployment is how EnforceAuth turns Git policy sources into OPA bundles at your bundle destination. The Deployments page is the audit trail: who triggered what, for which entity and environment, and whether the pipeline succeeded.
Open console.enforceauth.com/deployments.
Page overview
- Title: Deployments
- Subtitle: Policy deployment history · all entities · auto-refreshes every 60s
- Live controls: Pause / Resume auto-refresh, Refresh now, and a last-updated indicator
- Primary action: Deploy — pick entities and an environment to run the pipeline
The stats bar summarizes fleet activity:
| Segment | Meaning |
|---|---|
| INITIATED | All-time deployment count |
| IN PROGRESS | Runs currently executing |
| SUCCESSFUL | Success rate |
| FAILED | Failure rate |
Deployment run statuses
Each run has one of:
| Status | Meaning |
|---|---|
| Pending | Queued, not yet started |
| In Progress | Pipeline executing |
| Success | Bundle published to destination |
| Failed | Pipeline error — open detail for phase and logs |
| Timeout | Exceeded allowed duration |
Filter the table by status or search by run ID, entity name, or initiating user.
Pipeline phases
Open a run's Details to see the phase stepper:
Initializing → Fetching → Testing → Building → Deploying → Complete
Failures usually pinpoint which phase broke (clone, opa test, bundle build, or upload). Fix the underlying issue in Git or entity config, then redeploy.
What triggers a deployment
Runs record how they were initiated:
| Source | Label in UI |
|---|---|
| Manual console action | Manual |
| CI integration | GitHub Actions, GitLab CI, CircleCI, or CI/CD |
| Git webhook | GitHub, GitLab, Bitbucket, or Webhook |
Manual deploys use the Deploy dialog. CI and webhook deploys appear with the corresponding label so you can correlate console history with pipeline commits.
For GitHub Actions setup (trust policies, OIDC, deploy-action), see GitHub Actions and CI/CD.
Manual deploy workflow
- Click Deploy on the Deployments page.
- Select one or more entities. Only deployable entities are selectable — each needs an effective policy source and bundle destination (own or inherited). Ineligible rows show Not configured, Missing policy source, or Missing bundle destination.
- Choose Environment — the dialog uses the intersection of environments configured on the selected entities.
- Click Initiate Deployment.
The footer shows how many entities are selected. While running, the button reads Deploying....
Environments and promotion chains
Per-entity Environments configuration maps each environment name to a bundle destination (and optional branch/path overrides). Key fields:
- Promotes To — target environment when promoting (e.g. dev → staging). Choose No (end of chain) for production endpoints.
- Default environment — pre-selected in deploy dialogs
- Auto deploy — optional automation when Git changes land
EnforceAuth tracks drift between environments (In sync, N differences, Checking...). Compare bundle versions before approving production promotion.
The per-environment Promote button may show Promotion actions coming soon until the guided promote flow ships. Until then, deploy explicitly to each environment in your chain (dev → staging → prod) and verify drift indicators.
See Multi-environment best practices for regulated promotion rules.
Restore (rollback)
To roll back, open a successful historical run and click Restore (not "Rollback" in the UI).
Eligible restores re-activate that run's bundle as the live artifact. The UI explains ineligibility:
- Failed deployments can't be restored
- This deployment is not eligible for restore
- Original bundle aged out — will rebuild from source.
Confirm in the Restore Deployment dialog by typing RESTORE, then Restore Now.
Restored runs show a Restored badge. Tags include Restored from # run id or Rebuilt from # run id when the platform rebuilds from Git SHA instead of a cached artifact.
Deep-linking a run
Share or bookmark ?run=<run_id> on the Deployments page to open a specific run's detail dialog.
Relationship to policy status
Policy list statuses (ACTIVE, ERROR, DRAFT, DISABLED) reflect deployment outcomes. After a successful deploy, policies in that bundle move toward ACTIVE; failed test or build phases often correlate with ERROR policies until the next good deploy.
Verify success
- Run status Success and phase stepper reaches Complete
- Bundle version in the entity matches the expected Git commit
- Policies tab shows updated Last Edited / active status
- Decision logs reference the new bundle version under Decisions
Troubleshooting
| Symptom | Check |
|---|---|
| Entity not deployable | Policy source + bundle destination on entity or ancestor — Entity model |
| Fetching phase fails | GitHub App, PAT, branch, policy_path — Integrations troubleshooting |
| Deploying phase fails | S3/GCS/Azure credentials and write permissions — Integrations troubleshooting |
| Testing phase fails | opa test in repo; fix locally before redeploy |
| Success but PDP stale | Bundle destination URL and PDP pull interval — PDP integration |
| Drift between envs | Deploy missing environment; compare run IDs per env |