Circleci on Hold
You set up a circleci on hold step by adding an approval job to your workflow. This step pauses the build pipeline until a team member clicks approve in the web dashboard. Teams use this pause to check code before a live deploy runs. Still, broad project roles often let any developer approve their own changes and push bad scripts. How a circleci on hold workflow operates A pipeline runs jobs in a set order based on your workflow rules. Most jobs spin up a runner, pull code, and run tests righ
Single Sign-On (SSO) + CircleCI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a circleci on hold step by adding an approval job to your workflow. This step pauses the build pipeline until a team member clicks approve in the web dashboard. Teams use this pause to check code before a live deploy runs. Still, broad project roles often let any developer approve their own changes and push bad scripts.
How a circleci on hold workflow operates
A pipeline runs jobs in a set order based on your workflow rules. Most jobs spin up a runner, pull code, and run tests right away. An approval job works in a different way. It does not start a machine or run any scripts on its own.
Instead, the pipeline stops when it reaches the hold step. Downstream jobs that depend on this hold step wait in a paused state. The system sends an alert to your team chat or email list. A user with write permissions must log in to the web app to review the build. Once that user clicks the approve button, the downstream deploy jobs start to run. If no one clicks the button before the time limit ends, the workflow stops and expires.
Teams can also pair the hold step with restricted contexts. A context holds shared keys and secrets for live cloud targets. You can limit a context to a single security group from your source code host. When you attach that restricted context to the hold step, only group members can click approve. This setup stops general developers from pushing code to production on their own.
What native build pauses solve and miss
Native workflow pauses give your team a clear checkpoint before a release goes out. They stop broken tests from hitting live servers without a human check. Reviewers can check the commit history and test logs before they let the pipeline move forward. Using restricted contexts also ensures that only senior staff can trigger the final deploy step.
Yet a build pause only controls when a job starts. It does not check what the job does once it runs in flight. After a reviewer clicks approve, the runner loads all static keys stored in that context. The deploy script then runs with full admin power against your databases and cloud hosts.
Single Sign-On (SSO) + CircleCI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If a script holds a bad query, the pipeline still runs it in full. The approval log records who clicked the button in the web app. It does not log the exact database statements or shell commands that the job ran. Also, static secrets sit in the build settings for months at a time. Anyone who gains access to the runner during the job can read those keys. And if the deploy script queries user tables, raw emails or card numbers can leak into build logs.
Securing live actions beyond pipeline holds
Relying only on a pipeline pause leaves a wide gap during execution. A safe release flow needs controls at the command and query level too. Instead of handing broad static keys to a build runner, teams should inspect every live command. You should also mask sensitive fields like phone numbers or national IDs in query results. That way, build logs stay clean even when a deploy script reads live data.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why is my pipeline stuck in a circleci on hold state?
Your workflow has an approval job that waits for a manual click in the web dashboard. The build will not move forward until an allowed user approves that step.
Who can click approve on a paused workflow step?
By default, anyone with write access to the code repo can approve a paused job. You can limit this to specific teams by linking a restricted context to the hold job.
What happens if no one approves a paused workflow?
The platform keeps the workflow on hold until the built-in time limit runs out. Once that limit passes, the platform marks the hold step as expired and cancels downstream jobs.