Circleci Hold Step
A circleci hold step pauses your build pipeline until a team member approves the run. You add this approval job between test stages and production deploy jobs. Engineering teams use this gate to stop bad code from reaching live servers. Still, broad project roles often let any developer click the approve button. When too many people can approve builds, you lose control over production changes. How a circleci hold step works in your pipeline In your pipeline file, the hold step acts as a speci
CircleCI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A circleci hold step pauses your build pipeline until a team member approves the run. You add this approval job between test stages and production deploy jobs. Engineering teams use this gate to stop bad code from reaching live servers. Still, broad project roles often let any developer click the approve button. When too many people can approve builds, you lose control over production changes.
How a circleci hold step works in your pipeline
In your pipeline file, the hold step acts as a special job type. It does not spin up a container or run any shell scripts. Instead, the workflow engine stops and waits for a manual signal. Upstream jobs like unit tests and security scans must finish first. Once those pass, the pipeline marks the hold job as waiting.
Team members then log in to the web dashboard to check the build. They review the test results and click the approval button to continue. After someone approves the step, downstream deploy jobs start running right away. You can also link the workflow to chat tools for quick alerts. This setup keeps humans in the loop before live changes happen.
Why native pipeline gates leave gaps in production
A native hold job works well for basic release timing. It stops automated runs from pushing code during busy hours. It also gives quality teams time to check staging apps first. Yet this simple gate only checks who clicks the dashboard button. By default, anyone with write access to the repo can approve holds.
You can restrict approvals by setting up restricted contexts for your secrets. Even then, the gate only guards the start of the deploy job. Once the job starts, the runner loads static cloud keys into memory. The pipeline system does not inspect the exact commands or queries inside that job. If a build script contains a bad database drop command, it runs anyway. And if a developer starts an interactive debug session, they can read those keys. Native gates decide when a job runs, not what each command does in flight.
CircleCI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing database and cloud commands during deploy runs
To fix this gap, teams must separate build orchestration from target system permissions. Your pipeline should not hold long-lived admin keys for production databases. Instead, each command inside a deploy job should pass through fine-grained checks. You want to approve specific high-risk actions, not just whole pipeline stages.
Good security also requires clear logs of every query and script run. When a deploy job updates a database table, you need to know what ran. You also need to protect sensitive user data like emails and card numbers. Masking rules can rewrite those matched fields in query results during fixing runs. This approach turns a broad pipeline pause into precise runtime control.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Who can click approve on a circleci hold step?
By default, any user with write permissions on the source repo can approve it. You can limit this group by linking a restricted security context to the hold job.
Does a paused workflow consume build credits while waiting?
No, a hold job does not run on a virtual machine or container. It waits in the control plane and uses zero compute credits until approved.
How long will a pipeline wait for manual approval?
The workflow stays paused for a set number of days based on platform limits. If nobody approves the step before the timer ends, the workflow cancels itself.