Hosted Continuous Integration
You set up hosted continuous integration by linking your code repo to a cloud runner. The cloud service then runs your build and test steps on every code push. Most engineering teams start by storing database keys and cloud roles in the runner settings. When those roles are too broad, any build script can change or delete live data. How hosted continuous integration works A hosted continuous integration tool runs your build steps on remote cloud machines. You do not manage or patch these buil
Continuous Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up hosted continuous integration by linking your code repo to a cloud runner. The cloud service then runs your build and test steps on every code push. Most engineering teams start by storing database keys and cloud roles in the runner settings. When those roles are too broad, any build script can change or delete live data.
How hosted continuous integration works
A hosted continuous integration tool runs your build steps on remote cloud machines. You do not manage or patch these build servers yourself. Instead, the vendor starts a fresh virtual machine for each new code commit. The machine pulls your code, installs packages, runs tests, and sends back the results.
To deploy apps or run migration scripts, the runner needs permission to reach your servers. Teams grant this permission in two main ways. The first way is to save static keys inside the project secret store. The runner loads these keys into the job memory when a build starts. The second way uses short tokens from your cloud provider. The runner trades a job token for a temporary cloud role during the build.
Both methods rely on role settings inside your cloud or database accounts. You create a service role for the runner and attach permission rules to it. You also set up branch rules in your repo. These branch rules make sure only approved code merges can trigger a production build job.
What native build roles solve and what they miss
Native secret stores and cloud roles solve the basic login problem for your pipelines. They let a remote runner log in to your servers without putting passwords in code. Branch rules also help by blocking untrusted pull requests from loading production secrets. Together, these controls decide which build jobs can log in to a target server.
Still, login controls do not check what a build job does after it logs in. A migration runner often gets full table write permissions so it can update schemas. Once the runner logs in, it can run a destructive drop command by mistake. A broken script or a bad package can also read customer tables during a build.
Native build logs only show the text output that the job prints to the screen. They do not record the exact database queries or server commands run during the job. Also, native build tools do not mask sensitive fields in query results. If a script queries a table, emails, phone numbers, and card numbers can leak into logs. To fix this gap, teams need controls that inspect and filter individual commands in flight.
Continuous Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Securing database migrations and deploy steps in cloud runners
Database changes and live deploys are the riskiest steps in an automated build pipeline. A small mistake in a SQL script can lock tables or wipe out user records. When you run these steps from a cloud runner, nobody is watching the screen. The script runs at full speed with whatever permissions the build role holds.
To reduce this risk, split your build jobs into small steps with separate roles. Give your unit test job zero permissions to reach any live cloud server. Give your read checks a read-only role that only touches safe tables. Save write roles for the final deploy step after all tests pass.
Even with separate roles, a write step still holds broad power over your data. Teams still need a way to block dangerous commands and mask national IDs in results. Adding command checks and human approval steps keeps automated runs safe without halting code delivery.
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
How is hosted continuous integration different from self-hosted runners?
In a hosted setup, the vendor manages the build machines and cleans them after jobs. With self-hosted runners, your own team must boot, patch, and secure the build servers.
Should build pipelines use static keys or short-lived tokens?
Short-lived tokens are much safer because they expire right after the build job finishes. Static keys stay valid until a human rotates them, which raises the risk of leaks.
Why do build logs sometimes expose sensitive customer data?
Build scripts often print error details or query outputs to help engineers fix broken runs. If a query pulls real records, those raw fields get saved inside the build log.