Gitea: Self-Hosted Git Service with CI/CD and Packages

What Gitea is

Gitea is a self-hosted, all-in-one software development service written in Go. Its README states the goal plainly: to be the easiest, fastest and most painless way of setting up your own development platform, covering Git hosting, code management, code review, issue tracking, project kanban boards, a wiki, team collaboration, a package registry and CI/CD that can reuse GitHub Actions. The project is MIT-licensed and its GitHub repository dates back to November 2016.

It is aimed at teams and individuals who want the GitHub-style workflow (repositories, pull requests, issues, releases, Actions) on infrastructure they control: companies with data-residency or air-gap requirements, homelab and VPS operators, open-source communities that prefer not to depend on a single hosted platform, and organisations that want a lightweight internal forge without operating a large stack. Because it is a Go program, the README notes that it runs on every platform and architecture Go supports, including Linux, macOS, FreeBSD/OpenBSD and Windows, on x86, amd64, ARM, RISC-V 64 and PowerPC.

How it works

Gitea ships as a single server binary. In production builds the bindata build tag embeds all frontend assets into one monolithic executable, which is what makes it easy to copy onto a server and run. The binary serves the web UI and API, handles Git over HTTP, and in the official Docker image an integrated OpenSSH daemon handles Git over SSH. Running ./gitea web starts the server and ./gitea help lists the other commands.

Data lives in a database plus a data directory. The Docker installation guide shows that the simplest setup can initialise SQLite3, and it documents MySQL and PostgreSQL alongside it for larger installs. Configuration is split in two: dynamic options are changed from the admin panel, while static options live in app.ini and require a restart. In the Docker setup the configuration file ends up at /data/gitea/conf/app.ini after installation. Build-time variables let packagers move the custom path, config path and work path to locations such as /etc/gitea/app.ini and /var/lib/gitea.

CI/CD is handled by Gitea Actions, which runs workflows on a separate action runner. The documentation includes a page comparing Gitea Actions with GitHub Actions, reflecting the README's claim that it can reuse GitHub Actions workflows.

Key features

• Git hosting and code review. Repositories, branches, tags, releases and pull requests with review, plus protected branches and tags and code owners, as listed in the documentation.
• Issue tracking and planning. Issues, labels, milestones, issue and pull request templates, automatically linked references and project kanban boards.
• Built-in package registry. The documentation lists registries for Alpine, Arch, Cargo, Chef, Composer, Conan, Conda, containers, CRAN, Debian, Go, Helm, Maven, npm, NuGet, Pub, PyPI, RPM, RubyGems, Swift, Terraform state, Vagrant and generic packages.
• Gitea Actions. CI/CD with variables, secrets, artifacts, badges and job token permissions, executed by the Gitea runner.
• Wiki and collaboration. Per-repository wikis, organisations and teams, and a profile README.
• Repository tooling. Mirror repositories, template repositories, migrations from other services, webhooks, Git LFS, partial clone filters, blame view and GPG/SSH commit signatures.
• Authentication and security. Multiple authentication sources, multi-factor authentication, user blocking, an OAuth2 provider, audit logging and Fail2ban integration, according to the documentation index.
• Ecosystem. An official Go SDK, a CLI called tea, and a community list of third-party projects at awesome-gitea.

Getting started

The official documentation's Docker guide uses Docker Compose. A minimal docker-compose.yml from that guide, using SQLite3 and the rootful image:

networks:
  gitea:
    external: false
services:
  server:
    image: docker.gitea.com/gitea:28.2.0
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"

Then start it in the background and check that it came up:

docker compose up -d
docker compose ps
docker compose logs

Visit port 3000 on the server and follow the installation wizard. If you run the database through the same Compose file, the guide notes that db must be used as the database hostname. The host volume must be owned by the UID/GID set in USER_UID and USER_GID, or the container may not start.

To build from source instead, the repository's build guide uses make with the bindata tag, and Go's toolchain variables for cross builds:

TAGS="bindata" make build
GOOS=linux GOARCH=arm64 TAGS="bindata" make build

Shell completion can be generated with gitea completion <shell> for bash, fish, pwsh or zsh. Binary, package, Kubernetes, rootless Docker and Podman Quadlet installs are covered in the documentation.

Use cases

• Internal Git forge. Host company repositories, pull requests and issues on your own network, including environments with no internet access.
• Self-hosted CI. Run Actions-style workflows on your own runners, reusing existing GitHub Actions knowledge.
• Private package hosting. Publish npm, PyPI, Maven, container images and other artifacts next to the code that produces them.
• Mirrors and backups. Mirror important upstream repositories so builds keep working if an external host is unavailable.
• Homelab and small VPS setups. Run a full forge from a single container with SQLite for personal or small-team use.
• Community hosting. Give an open-source project its own forge with issues, wiki and releases.

How it compares

The documentation has a dedicated "Compared to other Git hosting" page, which is the best place to check specific features. In practice Gitea is usually weighed against hosted GitHub, self-managed GitLab and Gogs, another self-hosted Git service written in Go. Against hosted GitHub, the obvious difference is that you run Gitea yourself and keep code, issues, packages and CI on your own infrastructure. Against other self-hosted forges, its pitch per the README is ease of setup: a single Go binary or container that can start with SQLite and grow to MySQL or PostgreSQL. Feature sets on all of these change between releases, so compare them against your own requirements rather than relying on general reputation.

Things to know before adopting

• Licence. MIT, with no copyleft obligations for internal or modified deployments.
• Hosted options exist. Besides self-hosting, the README points to a free service at gitea.com with a limited number of repositories and to Gitea Cloud for dedicated instances with a free trial; the documentation site also links to an Enterprise offering. The self-hosted server remains MIT-licensed.
• Rootful vs rootless images. The Docker guide warns that the rootful and rootless images are not compatible with each other; pick one and stick with it.
• Version tags. The guide shows release tags such as 28.2.0 along with :latest, :main-nightly and per-branch nightly tags. Pin a specific release for production rather than tracking nightly builds.
• Upgrades and backups. The documentation has separate pages for backup and restore and for upgrading; read the release notes and security advisories on GitHub before upgrading.
• Actions runner is separate. CI needs the Gitea runner deployed alongside the server.

Project activity

As of October 2026 the repository has about 58,587 stars and more than 7,300 forks. It was created in November 2016, is written in Go and is licensed under MIT. The main branch receives frequent pushes, translations are managed through Crowdin, and security issues are reported privately to the project's security address.

Source code: github.com/go-gitea/gitea. Website: gitea.com. Documentation: docs.gitea.com. Demo: demo.gitea.com.