Gitea and Forgejo: Self-Hosted GitHub Alternative That Runs on a Raspberry Pi

Every team that reaches for self-hosted infrastructure eventually asks the same question about their code: do we really want our repositories on GitHub or GitLab's servers? GitHub is fine until it isn't — acquisition concerns, outages, pricing changes, or simply the principle that production infrastructure should live somewhere you control. GitLab self-hosted solves this but brings a significant operational footprint with it.

Gitea sits in the middle: the GitHub-style experience you're used to — repositories, pull requests, issues, releases, CI/CD — in a single Go binary that runs on hardware as modest as a Raspberry Pi. This post covers Gitea, its community fork Forgejo, when to choose each, and how to get either running in production.

What Gitea is

Gitea is a self-hosted Git service written in Go. It started in 2016 as a community fork of Gogs, motivated by Gogs' slow release pace, and has grown into the most popular standalone open source Git server with 55,000+ GitHub stars. The core bet: pack GitHub's core feature set into a single binary with no runtime dependencies, deployable anywhere from a Raspberry Pi to a Kubernetes cluster.

It's MIT licensed. One binary, a database (SQLite for small setups, PostgreSQL for production), and optional Redis for caching. That's the entire stack. Updates are a binary swap.

The feature set covers everything a development team actually needs day-to-day:

• Git hosting — repositories, branches, tags, releases, Git LFS
• Code review — pull requests with inline comments, review requests, protected branches
• Issues and projects — issue tracker, milestones, labels, kanban-style project boards
• Gitea Actions — CI/CD using the same YAML syntax as GitHub Actions, with the open source act_runner executor
• Container registry — Docker image hosting built in, no separate registry required
• Package registry — npm, PyPI, Maven, NuGet, Cargo, Helm, and more
• Wiki — per-repository wikis backed by Git
• Webhooks and API — REST API covering all resources, compatible with many GitHub API clients
• OAuth2 and LDAP — sign in with GitHub, Google, GitLab, or any OIDC provider; LDAP/Active Directory integration

The Forgejo fork — and why it matters in 2026

In late 2022, several long-time Gitea contributors and maintainers objected to governance decisions around the project — specifically concerns about the Gitea company potentially holding back features for a commercial tier and the lack of democratic project oversight. Those contributors forked the project as Forgejo (pronounced "for-JAY-oh"), now governed by an elected council under the umbrella of Codeberg e.V., a German non-profit.

This matters because Forgejo and Gitea have diverged in meaningful ways since the fork:

• License — Forgejo uses GPL v3 (copyleft), Gitea uses MIT. For organizations with procurement policies around copyleft, this matters.
• Governance — Forgejo has an elected council, public roadmap discussions, and no commercial entity. Gitea has a company (Gitea Limited) that makes decisions.
• ActivityPub federation — Forgejo is implementing ForgeFed, which will allow repositories and issues to federate across instances the way Mastodon federates across social servers. Gitea's roadmap on federation is less clear.
• Forgejo Actions — shipped GitHub Actions compatibility before Gitea Actions did. Both now have it.
• API compatibility — both share the same database schema and API at the core, so migration between them is straightforward.

The practical recommendation in 2026: for most new self-hosters, Forgejo is the safer default. Better governance, no commercial entity, more aggressive federation roadmap. If you need Gitea Enterprise features (SAML, advanced audit logs) or are deeply invested in the existing Gitea ecosystem, Gitea remains a valid choice. But if you're starting fresh, Forgejo is where the community momentum is.

Gitea Actions — the feature that removes the migration blocker

The biggest practical objection to leaving GitHub has always been the CI/CD rewrite cost. GitHub Actions has become the de facto standard for CI/CD workflows, with a huge ecosystem of pre-built actions and workflows. Rewriting everything to a different syntax is expensive.

Gitea Actions (and Forgejo Actions) uses the same YAML syntax as GitHub Actions. Many workflows migrate with minimal changes:

# .gitea/workflows/ci.yml (or .forgejo/workflows/ci.yml)
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          go test ./...
          go build ./...

The runner is act_runner — a separate binary you deploy alongside Gitea that picks up jobs and executes them. You register runners against your instance, and they appear in the CI/CD dashboard exactly like GitHub-hosted runners.

Not every GitHub Actions feature translates — some marketplace actions have GitHub-specific dependencies, and the hosted runner ecosystem is smaller. But for standard build/test/deploy workflows, the compatibility is high enough that most teams can migrate without rewriting from scratch.

Self-hosting Gitea

Docker Compose is the simplest production path. Gitea with PostgreSQL:

services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: unless-stopped
    environment:
      USER_UID: 1000
      USER_GID: 1000
      GITEA__database__DB_TYPE: postgres
      GITEA__database__HOST: db:5432
      GITEA__database__NAME: gitea
      GITEA__database__USER: gitea
      GITEA__database__PASSWD: ${POSTGRES_PASSWORD}
    volumes:
      - ./gitea-data:/data
    ports:
      - "3000:3000"
      - "2222:22"   # SSH clone port
    depends_on:
      - db

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: gitea
      POSTGRES_USER: gitea
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

For Forgejo, replace gitea/gitea:latest with codeberg.org/forgejo/forgejo:latest. The rest is identical.

Put Traefik in front for HTTPS and you have a complete Git hosting platform. Minimum viable server: 512MB RAM (SQLite) or 1GB+ (PostgreSQL). Gitea idles at around 400MB — compared to GitLab's multi-GB footprint, this is a dramatic difference.

A few production considerations:

• SSH port — expose port 22 or 2222 for SSH cloning. Without it, users are HTTPS-only.
• SMTP — configure for email notifications, password resets, and user registration emails.
• Storage — Git LFS and package registry artifacts need persistent storage. Plan accordingly.
• Backups — the gitea-data volume and PostgreSQL database are what you need to back up. Simple, predictable.

Migration from GitHub

Gitea and Forgejo both ship built-in migration tools that import from GitHub, GitLab, Bitbucket, and other Gitea/Forgejo instances — including issues, pull requests, wiki pages, releases, and labels. The built-in importer handles most of it automatically.

Author re-attribution requires each user to log in at least once before their commits get linked to their account — commits aren't retroactively re-attributed, but new activity will be.

For large organizations migrating many repositories, the REST API allows scripted migration. The GitHub-to-Gitea/Forgejo path is the cleanest — better tooling and more predictable results than migrating from GitLab.

Gitea vs GitLab vs GitHub

vs GitHub — GitHub has the network effect, the Actions marketplace, Copilot, and the world's open source community. Gitea/Forgejo replaces the code hosting, pull requests, issues, and CI/CD — not the social graph. If your team needs to publish open source or wants contributors to find your code organically, GitHub's network is irreplaceable. For private team code hosting, Gitea/Forgejo is a completely viable alternative.

vs GitLab CE — GitLab is feature-complete and deeply integrated, but it comes with a multi-service stack (Sidekiq, Puma, Redis, PostgreSQL, MinIO, the list goes on) that requires 4-8GB of RAM minimum and dedicated server expertise to operate. Gitea/Forgejo runs at a tenth of the resource cost. GitLab CE wins on advanced security scanning (SAST, DAST, dependency scanning), compliance features, and the depth of its CI/CD system. Gitea/Forgejo wins on operational simplicity.

The practical rule: if you have a dedicated platform team and need GitLab's feature depth, run GitLab. If you want Git hosting that just works on a modest server, run Gitea or Forgejo.

Who it's for

Good fit:

• Teams who want GitHub-style code hosting on their own infrastructure without GitLab's operational overhead
• Organizations with data sovereignty requirements — source code can't live on GitHub or GitLab.com
• Small to medium engineering teams (1-50 developers) who want a complete Git platform without dedicated DevOps to maintain it
• Self-hosters who want Git hosting alongside their other self-hosted tools (Plane, Outline, Dokploy, etc.)
• Teams already on GitHub Actions who want to self-host CI/CD without rewriting workflows

Not the right fit:

• Teams that need GitLab's advanced security scanning (SAST, DAST) — stick with GitLab
• Organizations that need the GitHub network effect for open source contributions
• Teams that need Gitea Enterprise features (SAML, advanced audit logs) on the free tier — those are paid

My take

Gitea and Forgejo are the answer to "we want GitHub-style code hosting, we want to own the data, and we don't want to run GitLab." That's a real requirement for a lot of teams, and both tools deliver on it cleanly.

The Forgejo fork is the more interesting story in 2026. The governance improvements are meaningful — having a non-profit council rather than a commercial entity making roadmap decisions matters for projects you intend to run for years. The ActivityPub federation work is ambitious and genuinely novel: if it ships well, it could change how open source collaboration works by removing the dependency on any single centralized forge.

For a new self-hosted deployment today: start with Forgejo. It's a drop-in Gitea replacement with better governance and a more transparent roadmap. The migration path between the two is well-documented if you ever need to switch. The resource footprint is negligible — add it to the same server running Traefik, Plane, and Outline and you barely notice it's there.