Gitea

Gitea is a self-hosted Git service written in Go: repository hosting, pull requests and code review, issue tracking, a package registry, and CI/CD through Gitea Actions, packaged as a single binary or container. It began in 2016 as a fork of Gogs, and it’s become one of the more common ways homelabbers replace GitHub or GitLab with something that runs entirely on their own hardware. A small VM, or even a Raspberry Pi 3 for light use, is enough to run it, which is the main reason people reach for it instead of GitLab specifically.

Gitea has since been forked again itself. In December 2022, a group of former Gitea maintainers launched Forgejo after Gitea’s assets and trademark were moved into a newly formed for-profit company without a community vote, according to Forgejo’s own announcement. Forgejo stays a drop-in replacement for Gitea and is hosted under the non-profit Codeberg e.V. today; it gets its own separate fiche on this site.

Why self-host Gitea instead of GitHub or GitLab?

GitHub keeps your repositories, issues, and CI history on someone else’s infrastructure and terms of service, private repos included. GitLab’s self-managed edition solves that specific problem but not the resource one: GitLab’s own installation docs list 8 vCPUs and 16GB of RAM as the baseline for a single-node install, dropping to a still-substantial 8GB only in a memory-constrained setup, plus 40GB or more of disk before a single repository is counted. Gitea’s own system requirements page puts a full install within reach of 2 CPU cores and 1GB of RAM for a small team, and calls a Raspberry Pi 3 powerful enough for light workloads. That gap, not a difference in core Git features, is why Gitea shows up so often in homelabs where GitLab would be complete overkill.

Installing Gitea with Docker

This follows the SQLite setup from Gitea’s own Docker installation guide, the config most homelabs start with. MySQL and PostgreSQL backends are documented separately for larger, multi-user instances.

networks:
  gitea:
    external: false

services:
  server:
    image: docker.gitea.com/gitea:1.26.4
    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"

1. Install Docker if it isn’t already on the host, save the file above as docker-compose.yml, and run docker compose up -d.
2. Match USER_UID and USER_GID to whoever owns the ./gitea folder on the host, or Gitea won’t be able to write to it.
3. Host port 222 maps to Gitea’s internal SSH server on 22, so cloning over SSH uses port 222, not the default 22, unless you change the mapping.
4. Open http://your-server-ip:3000 and finish the install wizard. SQLite is pre-filled and fine for a first instance, so the only real decisions are the site title and the first admin account.

docker compose up -d
docker compose logs -f server

Gitea vs GitLab vs GitHub

All three host Git repositories with issues, pull requests, and CI/CD, but they differ sharply in where they run and what they demand from the hardware underneath.

	Gitea	GitLab (self-managed)	GitHub
Hosting	Self-hosted only	Self-hosted or GitLab.com	GitHub.com, Enterprise Server sold separately
Minimum hardware	2 CPU cores, 1GB RAM	8 vCPU, 16GB RAM baseline	N/A, fully managed
CI/CD	Gitea Actions, GitHub Actions-compatible YAML	GitLab CI/CD, its own YAML syntax	GitHub Actions
Core license	MIT	MIT (Community Edition); paid tiers add proprietary features	Proprietary, closed source
Package registry	20+ formats built in	Built in	GitHub Packages

• Runs on hardware GitLab would choke on: 2 cores and 1GB RAM per Gitea’s own minimums, against GitLab’s 8 vCPU/16GB baseline
• MIT-licensed throughout, no open-core split between a free tier and paywalled features
• Gitea Actions reuses GitHub Actions’ YAML syntax, so most existing workflow files need little rewriting
• Built-in package registry covers 20+ formats without standing up a separate service

• No hosted equivalent to GitHub.com or GitLab.com from the core team, beyond the newer, separate Gitea Cloud product
• Smaller plugin and integration ecosystem than GitLab’s built-in security scanning and compliance tooling
• Self-registration is on by default and needs a manual config change before going public

Reaching a self-hosted Gitea instance from outside the house works like any other homelab service: a reverse proxy for a real HTTPS domain, or a private network tool if you’d rather not expose it publicly. Our Nginx Proxy Manager and Caddy fiches cover the reverse-proxy route, and Tailscale covers skipping public exposure entirely.

FAQ

Is Gitea free and open source?

Yes. It’s MIT-licensed, free for any use including commercial. Gitea Ltd sells a separate hosted Cloud and Enterprise tier, but neither is required to self-host the core software.

What’s the real difference between Gitea and GitLab?

Mostly hardware. Both host repositories with pull requests, issues, and CI/CD, but GitLab’s self-managed edition lists an 8 vCPU, 16GB RAM baseline, while Gitea’s docs put a small team’s install within reach of 2 CPU cores and 1GB of RAM.

Can Gitea run on a Raspberry Pi?

Yes, for light workloads. Gitea’s own system requirements page names a Raspberry Pi 3 as powerful enough, and the official Docker images are multi-arch.

What is Forgejo, and how is it different from Gitea?

Forgejo is a 2022 fork of Gitea, started by former Gitea maintainers after the project’s assets moved into a new for-profit company without a community vote. It’s a drop-in replacement hosted by the non-profit Codeberg e.V., rather than a company-backed project.

Does Gitea support GitHub Actions-style CI/CD?

Yes, through Gitea Actions, which reuses GitHub Actions’ YAML workflow syntax and much of its plugin ecosystem, so many existing workflow files carry over with little change.

For a solo developer or a small team’s private repositories, Gitea is usually the fastest way from a docker-compose file to a working Git server without the hardware bill GitLab would attach to the same job. Once an org needs the security scanning and compliance tooling GitLab bundles into its paid tiers, that’s the point where the extra CPU and RAM start paying for themselves instead.