Bitbucket Pipelines Deployment Variables
You set up bitbucket pipelines deployment variables by assigning key-value pairs to specific stages. These values pass into your build runner only when that stage runs. Teams often store database keys and cloud tokens inside these settings. Still, broad permissions let any build script run any command on the target system. If a bad script runs in that stage, it gets full control. How bitbucket pipelines deployment variables work in your workflow Automated builds need different values for test
Bitbucket Pipelines Security + Deployment Approval Gates: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up bitbucket pipelines deployment variables by assigning key-value pairs to specific stages. These values pass into your build runner only when that stage runs. Teams often store database keys and cloud tokens inside these settings. Still, broad permissions let any build script run any command on the target system. If a bad script runs in that stage, it gets full control.
How bitbucket pipelines deployment variables work in your workflow
Automated builds need different values for test, staging, and production runs. Workspace variables and repo variables apply to every single build step. In contrast, deployment variables belong only to one named stage. When a pipeline starts a production step, the runner fetches the matching production values. A test step cannot read the values made for production.
You can mark sensitive keys as secured inside the settings page. Secured values hide their plain text in the web view and build logs. If a script tries to print a secured key, the log shows stars instead. The build runner loads these values into the shell memory during the run. Once the step ends, the runner wipes the container and clears the memory.
Variable override order matters when you use the same key name twice. A deployment variable always overrides a repo variable or a workspace variable. This lets teams set a safe default key at the workspace level. Then, the production stage swaps in the real live key during release. You can also lock a production stage so only approved branches can trigger it.
Why variable scoping is not enough for safe releases
Scoping keys to a stage solves the problem of keeping secrets out of code. Developers do not need to put passwords or tokens into git files. It also stops a basic pull request build from reading live keys. Branch locks ensure that only merged main code can start a live release.
Still, this native setup leaves a big gap during the actual run. Variables only decide whether a runner can log in to a database or cloud. They do not check or restrict the commands that the runner sends next. Most teams give the release role full admin rights so schema updates never fail. That means a broken script can drop a table or read customer data.
Bitbucket Pipelines Security + Deployment Approval Gates: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Build logs also fail to show what happened inside the target database. You can see that the deployment script ran and finished with no errors. You cannot see the exact queries or data rows that the script touched. If a script reads user emails or card numbers, the build log misses it. Real safety requires checking every command in flight and masking sensitive fields like phone numbers.
Best practices for managing pipeline keys and roles
Start by splitting your stages into clear groups for test, staging, and live runs. Never share a single database user or cloud role across two different stages. If a test build fails or leaks, the key should only affect test data. Keep your live keys strictly inside the locked production stage.
Next, cut down the permissions on the roles that your pipeline uses. Do not give the build runner a root key just to make scripts easy. Create a narrow role that can only alter the specific tables it needs. Rotate your stored keys on a regular schedule so old tokens expire fast. Finally, pair your build logs with query logs and field masking for national IDs.
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
What is the difference between repository variables and deployment variables?
Repo variables are open to every pipeline step in that code project. Deployment variables only load when a step runs against their matching named stage.
Which variable wins if two variables share the exact same name?
The most specific scope always wins during the pipeline run. A deployment variable overrides a repo variable, and a repo variable overrides a workspace variable.
Can developers read secured variables from the build logs?
Secured variables replace their exact string match with stars in the log output. Still, a script with access to the runner can still encode and send them out.