Gitea Pipelines
To run gitea pipelines, you register a background runner and add a workflow file to your repo. The runner reads that file, builds your app, and runs tests on each push. Most teams start by storing long-lived database keys and server logins in repo secrets. When those roles are too broad, any branch push can run unsafe commands against production systems. How gitea pipelines work under the hood A pipeline starts when a developer pushes code or opens a pull request. The Git server sees this eve
Bitbucket Pipelines Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run gitea pipelines, you register a background runner and add a workflow file to your repo. The runner reads that file, builds your app, and runs tests on each push. Most teams start by storing long-lived database keys and server logins in repo secrets. When those roles are too broad, any branch push can run unsafe commands against production systems.
How gitea pipelines work under the hood
A pipeline starts when a developer pushes code or opens a pull request. The Git server sees this event and looks for workflow files in the repo. It then puts a new job into the work queue for an active runner. A runner is a separate worker machine that polls the server for waiting jobs.
When the runner claims a job, it spins up a clean container or local shell. The server sends the code and any stored secrets over to that worker machine. The runner executes each step in the workflow file from top to bottom. It runs tests, builds container images, or sends update scripts to remote servers. When the steps finish, the runner sends the text logs and exit status back.
Teams can scope runners and secrets at the repo, group, or system level. A system runner can pick up jobs from any project on the server. A repo runner only takes jobs from the project that owns it. Scoping these workers is the first step in keeping build tasks isolated from each other.
Securing runner roles and workflow secrets
Pipelines often need to touch real servers or databases to run migrations and deploy code. Teams enable this by placing database logins, cloud keys, or SSH keys into secret storage. During a job run, the worker loads those secrets into memory for the build scripts.
To keep this setup safe, teams should create a dedicated role for each pipeline. A staging pipeline should only hold keys for staging servers and test data. Production deploy jobs should require a protected branch or a manual sign-off before running. You should also avoid sharing one high-power runner across public and private repos.
Bitbucket Pipelines Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Even with good secret scoping, static keys in a pipeline create a real risk. If a bad script enters the build, it can read the secret from memory. The runner must also clean up its disk space after every single job finishes. Leftover files on a shared worker can leak keys to the next build in line.
What native pipeline controls leave open
Native pipeline rules control which branch or user can start a workflow job. They also control which secrets get passed into the worker machine at the start. Once the runner logs in to a database or server, those native checks stop.
The pipeline setup decides who logs in, not what individual statements do in flight. A migration job with a write login can drop a table by mistake. A deploy script can read live customer emails, phone numbers, or card numbers in results. Native pipeline logs only capture standard output, not the exact queries sent to the database.
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 do gitea pipelines run jobs on remote servers?
You register a runner agent on a host machine using a token from the server. The agent polls the server for jobs, pulls the repo code, and runs the steps.
Where should teams store secrets for gitea pipelines?
Store secrets in the built-in secret store at the repo or group level. Scope each secret to the smallest group of projects that need it to run.
Why are static database keys risky inside pipeline runners?
Static keys stay valid long after the build job ends and grant full role access. Any script in that job can use the key to run unapproved queries or commands.