Self-hosted CI CD
You set up a self hosted ci cd system by installing a build server and worker agents on your own machines. These workers pull code from your git repo, run tests, and push apps to live servers. Many teams start by giving one shared admin role to every build worker. That broad role lets any broken script or bad commit change live databases and cloud resources. How a self hosted ci cd setup works A build system has two main parts that work together. The central server watches your git repos and
CI/CD Credential Management + Self-Service Access Portals: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a self hosted ci cd system by installing a build server and worker agents on your own machines. These workers pull code from your git repo, run tests, and push apps to live servers. Many teams start by giving one shared admin role to every build worker. That broad role lets any broken script or bad commit change live databases and cloud resources.
How a self hosted ci cd setup works
A build system has two main parts that work together. The central server watches your git repos and queues up new jobs. Worker agents run on separate virtual machines or containers inside your private network. Each worker asks the central server for the next job in the queue.
When a developer pushes code, the server sends the build steps to an idle worker. The worker pulls the source code and reads the secret keys it needs for the job. Teams store these keys in the central server or in an external secret store. The worker then builds the app, runs tests, and sends the changes to your servers.
To make this work, admins assign machine roles or static keys to the worker nodes. Because the workers sit inside your private network, they can reach internal databases and servers directly. Teams often Scope roles by project or branch so test jobs cannot touch live systems. The central server also keeps a basic text log of the console output for each build.
What native runner permissions solve and where they fall short
Native runner controls and cloud roles help you decide which worker can start a session. You can lock down your secret store so only release branches read live database keys. You can also put workers in separate network zones to keep test jobs away from live apps. These steps stop random outside users from triggering builds or stealing stored keys from the server UI.
Still, role checks only happen when the job starts or fetches a key. Once a worker logs in to a database or cloud host, the native setup stops watching. It does not check what individual SQL queries or shell commands do while the job runs. If a script has a bug, it can drop a table or read customer data.
CI/CD Credential Management + Self-Service Access Portals: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Build logs also fall short when you need to audit what happened inside a target system. The build log shows that a migration script ran, not the exact queries sent over the wire. Also, if a build fails, engineers often log in to the worker or database to fix it. Native build tools do not inspect those live debug commands or mask sensitive fields like emails and card numbers.
Managing live debug tasks and database changes in pipelines
Real pipelines need more than automated build steps to keep apps running. Engineers often need to run a quick database fix or check a broken state after a deploy. If they use the same broad keys that the worker uses, you lose track of who did what. Shared machine keys make every query look like it came from the build server itself.
To keep control, teams must separate automated build runs from human debug sessions. Every action against a live database or server should tie back to a single person or specific job. You also need a way to review risky commands before they run against live data. Masking fields like phone numbers and national IDs in query results keeps raw data out of logs and screens.
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 sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do teams pick self hosted ci cd over cloud runners?
Teams run their own workers to keep source code and build keys inside their private network. It also lets them use custom hardware and reach internal servers without opening public firewall ports.
How should we store database keys for build workers?
Do not put plain text keys in your git repo or worker disk files. Store keys in a central secret store and only pass them to the worker memory during the job.
What is the biggest risk with private build runners?
The biggest risk is giving worker nodes broad network reach and permanent admin keys. Any person who can edit the build script can run commands with the full power of that worker.