Circleci Promote Build
You set up a circleci promote build workflow by adding an approval job between stages. This manual step pauses your pipeline until a team member approves the release. Most teams use this pattern to move tested artifacts from staging into production. Still, broad role permissions often let any developer click approve and run production deploy scripts. When deploy jobs hold wide database keys, one bad push can change live records. How a circleci promote build workflow operates A promotion pipel
CircleCI Security + Build Provenance (SLSA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a circleci promote build workflow by adding an approval job between stages. This manual step pauses your pipeline until a team member approves the release. Most teams use this pattern to move tested artifacts from staging into production. Still, broad role permissions often let any developer click approve and run production deploy scripts. When deploy jobs hold wide database keys, one bad push can change live records.
How a circleci promote build workflow operates
A promotion pipeline separates artifact creation from artifact deployment across distinct stages. First, the build job compiles your app code and runs automated unit tests. Next, the pipeline saves the compiled package into a central storage bucket or registry. A staging job then pulls that exact package and deploys it to a test server.
At this point, the workflow hits a special hold step and pauses execution. The pipeline waits for a human to check the staging app and confirm it works. Once a user with the right role clicks approve, the final deploy job starts. That job pulls the same verified package and pushes it to the live servers. You never rebuild the code between staging and production.
Setting up role rules and secret contexts
To lock down who can approve a release, teams pair hold steps with restricted contexts. A context is a named group of secret keys shared across pipeline projects. You can link a context to specific security groups in your source code host. Only members of those security groups can trigger jobs that use that secret context.
When a developer outside the group tries to approve the hold job, the platform blocks them. This setup stops unauthorized team members from pushing unverified code to live systems. It also keeps production deploy keys separate from test and development jobs. You should create one context for staging keys and a stricter one for production keys.
CircleCI Security + Build Provenance (SLSA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where native pipeline promotion controls fall short
Restricted contexts and approval steps solve the problem of who can start a deploy job. They confirm that a trusted user clicked the button and passed the group check. Still, native pipeline gates only control the start of the job, not its actions. Once the deploy job starts, it loads raw database keys into the runner memory.
The native pipeline cannot inspect individual commands or database queries while the job runs. If a deploy migration script contains a bad drop statement, the runner executes it anyway. Likewise, if an engineer debugs a failed promotion via SSH, the pipeline logs lack command details. Teams also struggle when support scripts read live tables containing user emails or card numbers. Without runtime query checks and data masking, a valid promotion job still carries high risk.
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
What is the main benefit of promoting a build instead of rebuilding it?
Promoting a single artifact ensures the exact code you tested in staging runs in production. Rebuilding from source can introduce new package versions or subtle build differences at the last minute.
How do I restrict who can click the approval button in a pipeline?
You attach a restricted context to the job that follows the manual approval step. Then you limit that context to a specific team group in your version control system.
Can pipeline approval steps block destructive database migrations during a deploy?
No, native approval steps only check if a user has permission to start the job. They do not inspect or block individual SQL statements once the migration script starts running.