gitea

What is gitea?

The gitea image provides a full-featured, self-hosted Git platform written in Go. It covers the core workflows teams rely on: repository hosting, pull requests, issue tracking, project boards, a built-in package registry for OCI images and Helm charts, and Gitea Actions — a GitHub Actions-compatible CI/CD runtime. Because it's written in Go, it runs efficiently on modest hardware, making it popular for on-premises deployments, air-gapped environments, and teams that need full control over their source code without operating a heavier platform like GitLab.

The image runs both the Gitea web interface (port 3000) and an SSH server (port 22) for Git operations, and supports PostgreSQL, MySQL, and SQLite as its backing database.

How to use this image

Gitea is most commonly deployed via its official Helm chart for Kubernetes, or with Docker Compose for simpler setups. It requires a persistent volume for repository data and a database — PostgreSQL is recommended for production.

Install via Helm:

helm repo add gitea-charts https://dl.gitea.com/charts/
helm repo update
helm install gitea gitea-charts/gitea \
  --namespace gitea --create-namespace \
  --set gitea.admin.username=admin \
  --set gitea.admin.password=changeme \
  --set postgresql-ha.enabled=true
To use echo's image, override the repository in your Helm values:
image:
  repository: registry.echo.ai/gitea/gitea
  tag: latest
  rootless: true

After the pod starts, Gitea is accessible on port 3000 via the configured ingress. Repository data is stored in the mounted PVC under /data, and all configuration can be managed declaratively through GITEA__ environment variables, which the container maps into the app.ini configuration file at startup. Logs are written to stdout and are accessible via standard Kubernetes logging.

Image variants

Published under gitea/gitea, the image ships two main variants:

• gitea:<version> — The standard image, running as root internally. The default variant and the most broadly compatible option. Required when using features like SSH passthrough that depend on system-level permissions.
• gitea:<version>-rootless — Runs the Gitea process as a non-root user, making it the preferred choice for security-hardened Kubernetes environments and clusters with restrictive pod security policies. Note that the rootless variant uses a different internal directory structure than the standard image, so migrating between the two requires moving repository data on the PVC.

Both variants are versioned together with each Gitea release (e.g., 1.22.0, 1.22.0-rootless). Production deployments should pin to explicit version tags. The latest and latest-rootless tags track the most recent stable release and are useful for evaluation but not recommended for production.