Gitea CI CD
You set up gitea ci cd by enabling built-in actions and registering a runner. You then add a workflow file to your code repo to run jobs. Most teams store static cloud keys and database passwords inside the repo settings. This common setup creates high risk when runner roles have broad network permissions. A bad script or stolen token can read or delete production data fast. How gitea ci cd works in your repo Gitea includes a built-in automation system that works much like GitHub Actions. A s
CI/CD Credential Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up gitea ci cd by enabling built-in actions and registering a runner. You then add a workflow file to your code repo to run jobs. Most teams store static cloud keys and database passwords inside the repo settings. This common setup creates high risk when runner roles have broad network permissions. A bad script or stolen token can read or delete production data fast.
How gitea ci cd works in your repo
Gitea includes a built-in automation system that works much like GitHub Actions. A small background agent called an act runner does the actual build work. You install this runner on a separate host or inside a container. The runner polls the main Gitea server to check for new jobs. This pull design means the Gitea server does not push network traffic outward.
Developers define build steps inside a workflow text file in the code repo. When someone pushes code or opens a pull request, Gitea reads that file. The server adds the job to a queue and waits for a free runner. The runner claims the job, pulls the code, and starts a fresh container. Each step in the workflow runs inside this temporary container.
Pipelines often need to talk to outside cloud accounts, servers, or databases. Gitea lets admins store secret values at the repo, group, or system level. When a job starts, the server sends the needed secrets to the runner. The runner loads those values into the container memory so scripts can log in.
How runner permissions and secrets work
You can scope runners to serve the whole system, one team, or one repo. Shared runners save money because many projects use the same build machines. Yet shared runners also mix workloads from different teams on the same host. If a runner uses a local Docker socket, jobs can break out of containers. An attacker who controls one build script might read data from another job.
Secret scoping helps limit which repos can read specific passwords or keys. Repo secrets only go to jobs that run for that single code repo. Team secrets apply across a group of repos owned by the same group. Gitea also holds back secrets from pull requests sent by outside forks. This rule stops strangers from changing a build file to print your keys.
CI/CD Credential Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native gitea ci cd leaves open
Native secret storage solves the problem of keeping passwords out of git history. It also controls which repo can start a build with a given key. Still, this setup only decides who logs in to a target system. Once the runner logs in, the target database or host trusts the whole session.
The native pipeline cannot check what individual commands or queries do in flight. A migration job needs database write rights to add a new table. With static credentials, that same job could also drop a production table by mistake. If a build script runs a query on user tables, it gets raw data. Native runner controls do not rewrite emails, phone numbers, or card numbers in results. You also get job build logs, not a full record of every database query.
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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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
Can I use external CI tools instead of built-in Gitea actions?
Yes, Gitea sends standard webhooks when developers push code or open pull requests. External tools like Woodpecker, Drone, or Jenkins can listen for these events and run builds.
How does the act runner talk to the Gitea server?
The runner uses a registration token to link itself to the Gitea server. It then makes outbound requests to the server to pick up waiting jobs.
Why should I avoid sharing one database key across all repo pipelines?
A shared key gives every build job the same broad database permissions. If one repo pipeline gets compromised, the attacker can alter data across all projects.