Circleci Hold Approval
You set up a circleci hold approval by adding a manual pause job to your pipeline file. This special step stops the workflow until an authorized person clicks approve in the web dashboard. Engineering teams use this pause to check build logs before pushing new code to live servers. Still, broad project roles often let too many developers approve sensitive production runs by mistake. How a circleci hold approval works in your pipeline A build pipeline runs a list of jobs in a set order from st
Approval Chains & Escalation + CircleCI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a circleci hold approval by adding a manual pause job to your pipeline file. This special step stops the workflow until an authorized person clicks approve in the web dashboard. Engineering teams use this pause to check build logs before pushing new code to live servers. Still, broad project roles often let too many developers approve sensitive production runs by mistake.
How a circleci hold approval works in your pipeline
A build pipeline runs a list of jobs in a set order from start to finish. Most jobs start a virtual machine or container to test, build, or ship your app code. An approval job is different because it does not start a compute machine at all. Instead, the workflow engine reads the job type and puts the pipeline into a waiting state.
Downstream jobs that depend on this pause step will wait and do nothing right now. A team member must log in to the web dashboard and click the resume button. Once that person clicks the button, the downstream deployment jobs start running on fresh machines. You can also attach secret context groups to that pause step to limit who clicks approve.
Context security groups link to the user teams in your source code provider account. Only members of the chosen team can click the button or read the secret keys downstream. This design links human sign-off with the secret keys needed for the next deployment step. The build system logs the user name and time whenever someone clicks the resume button.
What native pipeline pauses solve and what they miss
Native pipeline pauses stop bad code from reaching live servers before a human checks the build. They give release managers a clear moment to read test results and review staging apps. When paired with restricted contexts, they also stop junior developers from triggering a production push.
Still, a pipeline pause only decides if the next job script starts running or not. Once a user clicks approve, the deployment job gets full network and key permissions right away. The build runner pulls static cloud keys or database passwords from the secret store into memory. The pipeline tool does not check the single commands or database queries inside that script.
Approval Chains & Escalation + CircleCI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If a deployment script has a bad migration query, the approved job runs it without warning. If a developer changes the build script to print secret keys, the runner obeys the script. Also, broad repo write roles often grant approval rights to every developer on the team. Teams need a way to check individual commands in flight and mask sensitive data fields.
Best practices for safer deployment reviews
Keep your approval jobs separate from your build and test jobs in the workflow graph. Run all unit tests, security scans, and build steps before the pipeline hits the pause step. Reviewers should know that a waiting build already passed every automated check in the suite.
Limit the secret context on the pause job to a small group of senior leads. Do not reuse the same secret context across test, staging, and live production deployment steps. Rotate the static keys stored inside your build contexts on a strict monthly schedule. Finally, review your build audit logs every week to see who approved live software releases.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Who can click a circleci hold approval button by default?
By default, anyone with write permissions on the source code repo can click the approval button. You must attach a restricted context to the pause job to limit it to specific teams.
Does a paused workflow use compute credits while waiting?
No, a paused job does not start a container or virtual machine while it waits. You only spend compute credits when the upstream or downstream jobs run active build scripts.
What happens if nobody clicks the approval button?
The workflow stays in a waiting state until the platform time limit expires and cancels it. Downstream jobs that depend on the pause step will never start if the timer runs out.