Gitea Actions runner registration is a CI trust decision

Gitea Actions uses runners to execute jobs from repositories. A runner registers with a Gitea instance and receives work through its connection. Registration is the point where the forge decides that a new execution environment belongs to its CI system.

Gitea's runner documentation describes registration tokens and supports passing a token through a file or environment variable to keep it out of shell history and process listings. The documentation also describes ephemeral runners as a hardening option for organization or instance-wide use. Those choices matter because a runner usually receives source code, job tokens and deployment credentials.

What ZoomEye can and cannot show

On 2026-11-09 at 06:47 Asia/Shanghai, the ZoomEye probes used page 1, page size 1 and sub_type=all:

  • app="Gitea": 118,554
  • title="Gitea": 122,012
  • http.body="Act Runner": 76

The app and title counts describe visible Gitea instances, not runner daemons. The Act Runner body query found 76 pages that contain the phrase, which may include documentation. No count proves that a runner is open, over-privileged or able to execute untrusted code.

Scope the registration token

Use an organization or repository registration token when that is the intended boundary. An instance-wide token can enroll a runner that receives jobs from many owners. Keep the token in a secret manager and load it from a protected file or environment. Do not put it in a public repository, build log or command history.

Rotate the registration token after a runner is lost or an administrator changes. Revoke the runner identity as well. Deleting the container without removing the runner record can leave a dormant identity that is eligible for future work.

Limit what a job can reach

A runner executes code supplied by the repository. Treat that code as untrusted unless the organization has a stronger policy. Use a disposable container or virtual machine, a non-root user and a restricted network. Mount only the tools required for the job.

Separate runners by trust level. Public repositories should not share a runner with production deployment jobs. A job token should be scoped to the repository and expire quickly. Deployment credentials should be issued only after the job has passed the expected review or branch policy.

Review labels and routing

Runner labels determine which jobs can target an environment. A label such as production or deploy should not be available to every repository. Audit who can change workflow files and which labels those workflows can select. A misrouted job can put secrets on the wrong runner even when the registration token was managed correctly.

Log runner registration, removal, label changes and job start events. Alert on a new runner from an unexpected network or a registration at an unusual time. The Gitea administrator should compare the runner inventory with the deployment system's expected hosts.

Deployment checks

  1. The registration token is stored outside source and logs.
  2. A runner has a narrow repository or organization scope.
  3. Public jobs cannot select deployment labels.
  4. The runner filesystem and network are disposable.
  5. The forge removes a runner after its environment is destroyed.

The observed Gitea population is much larger than the narrow Act Runner phrase count. That gap is useful context: a visible forge does not reveal the runner fleet behind it. Manage registration as a trust decision, keep tokens out of process listings and make each runner's scope match the code it is allowed to execute.

References