Gitea vs Forgejo: Lightweight Self-Hosted Git 2026

TL;DR

Gitea (MIT, ~44K GitHub stars, Go) and Forgejo (GPL 3.0, ~10K stars, Go) are both lightweight self-hosted Git services. Forgejo is a community-governed fork of Gitea, created in 2022 after concerns about Gitea Ltd's commercialization direction. They're functionally nearly identical today, but the choice between them is increasingly important: Forgejo has more active community governance and stronger federation plans; Gitea has more third-party integrations and a larger ecosystem. Both run in under 200MB RAM with full GitHub-like features.

Key Takeaways

• Gitea: MIT, ~44K stars, Go — original project, largest ecosystem, commercial-friendly
• Forgejo: GPL 3.0, ~10K stars, Go — community fork, stronger copyleft, federation (ActivityPub) roadmap
• Both include: Actions CI/CD, container registry, issue tracker, wikis, webhooks, API
• RAM: ~100–200MB — vastly lighter than GitLab (~4GB)
• Migration: Trivial to migrate between them (same codebase fork)
• Choose Gitea: Better third-party tool support (VS Code extensions, bots, CI integrations)
• Choose Forgejo: Community governance, copyleft license, federation plans

---

Gitea vs Forgejo vs GitLab CE

Feature	Gitea	Forgejo	GitLab CE
License	MIT	GPL 3.0	MIT
GitHub Stars	~44K	~10K	~24K
RAM (idle)	~100MB	~100MB	~4GB+
CI/CD	Gitea Actions	Forgejo Actions	GitLab CI
Container Registry	Yes	Yes	Yes
Pages	Yes	Yes	Yes
Federation	Planned	In progress	No
LDAP/OIDC SSO	Yes	Yes	Yes
PostgreSQL support	Yes	Yes	Yes
Self-hosted runners	Yes	Yes	Yes

---

Part 1: Gitea Docker Setup

# docker-compose.yml
services:
  gitea:
    image: gitea/gitea:latest
    container_name: gitea
    restart: unless-stopped
    ports:
      - "3000:3000"
      - "2222:22"    # SSH for git push
    volumes:
      - gitea_data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    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}"
      GITEA__server__DOMAIN: "git.yourdomain.com"
      GITEA__server__ROOT_URL: "https://git.yourdomain.com/"
      GITEA__server__SSH_DOMAIN: "git.yourdomain.com"
      GITEA__server__SSH_PORT: "2222"
      GITEA__service__DISABLE_REGISTRATION: "true"
    depends_on:
      - db

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

volumes:
  gitea_data:
  db_data:

---

Part 2: Forgejo Docker Setup

Forgejo uses the same config format as Gitea — just change the image:

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:latest
    container_name: forgejo
    restart: unless-stopped
    ports:
      - "3000:3000"
      - "2222:22"
    volumes:
      - forgejo_data:/data
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      FORGEJO__database__DB_TYPE: postgres
      FORGEJO__database__HOST: db:5432
      FORGEJO__database__NAME: forgejo
      FORGEJO__database__USER: forgejo
      FORGEJO__database__PASSWD: "${POSTGRES_PASSWORD}"
      FORGEJO__server__DOMAIN: "git.yourdomain.com"
      FORGEJO__server__ROOT_URL: "https://git.yourdomain.com/"
      FORGEJO__service__DISABLE_REGISTRATION: "true"
    depends_on:
      - db

docker compose up -d

---

Part 3: HTTPS with Caddy

git.yourdomain.com {
    reverse_proxy localhost:3000
}

SSH clone: Users clone via SSH using port 2222:

git clone ssh://git@git.yourdomain.com:2222/username/repo.git

---

Part 4: Initial Setup

1. Visit https://git.yourdomain.com
2. Installation wizard → verify database settings
3. Create admin account
4. Register additional users (or invite via email if registration disabled)

Add your SSH key:

# User settings → SSH/GPG Keys → Add Key
cat ~/.ssh/id_ed25519.pub

---

Part 5: Actions CI/CD

Both Gitea and Forgejo support GitHub Actions-compatible workflows (using .gitea/workflows/ or .forgejo/workflows/).

Set Up a Runner

# On a separate host or same host:
services:
  gitea-runner:    # or forgejo-runner
    image: gitea/act_runner:latest
    container_name: gitea-runner
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - runner_data:/data
    environment:
      GITEA_INSTANCE_URL: "https://git.yourdomain.com"
      GITEA_RUNNER_REGISTRATION_TOKEN: "${RUNNER_TOKEN}"
      GITEA_RUNNER_NAME: "docker-runner"
      CONFIG_FILE: /data/config.yaml

Get the registration token: Admin Panel → Runners → Create new runner.

Example Workflow

# .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: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          
      - name: Install dependencies
        run: npm ci
        
      - name: Run tests
        run: npm test
        
      - name: Build
        run: npm run build

---

Part 6: Container Registry

Both Gitea and Forgejo include a built-in container registry:

# Log in:
docker login git.yourdomain.com

# Tag and push:
docker tag myapp git.yourdomain.com/username/myapp:latest
docker push git.yourdomain.com/username/myapp:latest

# Pull:
docker pull git.yourdomain.com/username/myapp:latest

In your Actions workflow:

- name: Build and push Docker image
  run: |
    echo "${{ secrets.GITEA_TOKEN }}" | docker login git.yourdomain.com -u ${{ gitea.actor }} --password-stdin
    docker build -t git.yourdomain.com/${{ gitea.repository }}:${{ gitea.sha }} .
    docker push git.yourdomain.com/${{ gitea.repository }}:${{ gitea.sha }}

---

Part 7: Migrate Between Gitea and Forgejo

Since Forgejo is a fork of Gitea, migration is trivial:

Gitea → Forgejo

# 1. Stop Gitea:
docker compose down

# 2. Back up data:
tar -czf gitea-backup.tar.gz $(docker volume inspect gitea_gitea_data --format '{{.Mountpoint}}')

# 3. Change image in docker-compose.yml:
#    gitea/gitea:latest → codeberg.org/forgejo/forgejo:latest

# 4. Update env var prefixes (optional — Gitea vars work in Forgejo too):
#    GITEA__ → FORGEJO__ (in new configs)

# 5. Start:
docker compose up -d

Forgejo reads Gitea's data directory natively — no data migration needed.

---

Part 8: OIDC / SSO Integration

Connect to Authentik, Keycloak, or other OIDC providers:

In Admin Panel → Authentication Sources → Add OAuth2:

• Provider: OpenID Connect
• Client ID: from your OIDC provider
• Client Secret: from your OIDC provider
• OpenID Connect Auto Discovery URL: https://auth.yourdomain.com/application/o/gitea/.well-known/openid-configuration

Users can now log in via SSO.

---

When to Choose Gitea vs Forgejo

Choose Gitea if:

• You need maximum third-party ecosystem support (VS Code extensions, bots, integrations)
• You want MIT license (more permissive for commercial use)
• You're following a specific tutorial that uses Gitea
• You have existing Gitea users/scripts

Choose Forgejo if:

• You prefer community governance over corporate-influenced development
• GPL 3.0 license aligns with your values
• You're excited about ActivityPub federation (repos federated across Forgejo instances)
• You're hosted on Codeberg or similar Forgejo-native platforms

---

Maintenance

# Update:
docker compose pull
docker compose up -d

# Backup via built-in tool:
docker exec gitea gitea admin dump -c /data/gitea/conf/app.ini

# Or direct volume backup:
tar -czf gitea-backup-$(date +%Y%m%d).tar.gz \
  $(docker volume inspect gitea_gitea_data --format '{{.Mountpoint}}')

# Logs:
docker compose logs -f gitea

The License Divergence: Why It Matters More Than Stars

The difference between Gitea's MIT license and Forgejo's GPL 3.0 is more consequential than a casual comparison might suggest, especially for organizations that care about software freedom or are subject to procurement policies that favor copyleft licensing.

MIT is permissive: you can use, modify, and distribute Gitea's code — including incorporating it into a proprietary product — without any obligation to share your changes. This is why Gitea has better third-party ecosystem support. Commercial toolmakers (VS Code extension developers, CI/CD platform integrators, bot authors) are more willing to invest in integrations with MIT-licensed software because they don't need to open-source their integration code.

GPL 3.0 is copyleft: if you distribute modified versions of Forgejo, you must release those modifications under GPL 3.0 as well. For pure self-hosting purposes, this distinction rarely matters — you're not distributing the software, just running it. But for organizations building products on top of their Git hosting infrastructure, or for teams considering white-labeling a Git service, the licensing constraint is real.

The governance story is the flip side. Forgejo emerged specifically because a subset of the Gitea community was uncomfortable with Gitea Ltd's increasing commercial influence over project direction. The concern was that commercial priorities might drive feature decisions and licensing changes in ways that weren't aligned with the interests of self-hosting users. Forgejo's governance model is explicitly community-led — no single company controls the project, releases, or roadmap.

This matters if you're making a multi-year infrastructure commitment. With Gitea, you're trusting that Gitea Ltd's commercial interests will remain aligned with the self-hosting community's needs. With Forgejo, the community governance structure makes a unilateral pivot toward commercialization structurally harder. For teams that have been burned by open-core licensing changes (HashiCorp's BSL move being the most prominent recent example), Forgejo's governance model offers more predictable long-term stability.

For a comprehensive view of how the self-hosted Git hosting landscape compares to managed options, the key question is whether GitHub, GitLab.com, or Bitbucket Cloud offers features that justify their cost and data dependency for your team. For most small to mid-size teams, Gitea or Forgejo provides 95% of what GitHub offers at a fraction of the cost, with the added benefit of keeping your code on infrastructure you control. Teams in regulated industries or subject to data residency requirements find this particularly valuable.

Integrating Gitea or Forgejo into a CI/CD Pipeline

The Actions CI/CD feature in both Gitea and Forgejo is the capability that moves these platforms from "GitHub Lite" to a viable alternative for production development workflows. GitHub Actions compatibility means most existing Actions workflows can be imported with minor adjustments, and the community of reusable Actions can be used with the Gitea/Forgejo act runner.

The runner setup deserves more attention than the quick summary in Part 5 suggests. For teams doing serious CI/CD work, running the act runner on the same server as your Git hosting is convenient but creates resource contention. A more robust setup uses a separate runner host — even a small 2-core VPS at $5/month gives you isolated CI resources that won't slow down your Git server when multiple pipelines run simultaneously.

Multi-platform builds work well with the self-hosted runner model. You can register runners on ARM hosts (Raspberry Pi, Oracle Cloud's free ARM instances, Hetzner CAX) alongside x86 runners, and tag them appropriately in your workflow files. This gives you native ARM builds without emulation overhead — something GitHub Actions charges extra for via larger runners and something GitLab.com's free tier doesn't support at all.

Combining Gitea or Forgejo with a PaaS deployment platform creates a complete self-hosted CI/CD pipeline. The flow looks like this: developer pushes to a Gitea repository, an Actions workflow runs tests and builds a Docker image, pushes the image to Gitea's built-in container registry, and then triggers a Coolify or Dokku deployment via webhook or API call. The entire pipeline runs on infrastructure you control, with no data leaving your servers. Compared to the alternative of GitHub + GitHub Actions + Docker Hub + a deployment platform, the self-hosted version is architecturally simpler and eliminates three external service dependencies.

For database and configuration backup within this infrastructure, the Gitea data directory and PostgreSQL database need to be part of your backup rotation. Automated server backups with Restic and Rclone covers how to include Docker volume data — including Gitea's repositories and issue data — in an encrypted, deduplicated backup that runs daily to an offsite cloud storage provider. Losing your Git hosting data without a backup is catastrophic; Restic's deduplication means the storage cost of daily repository backups is lower than you'd expect for a typical codebase.

Forgejo's Federation Roadmap: The Long-Term Vision

One aspect of Forgejo that doesn't get enough attention is its active work on ActivityPub federation — the same protocol that powers Mastodon and other decentralized social platforms. The vision is that Forgejo instances will be able to discover and interact with repositories on other Forgejo instances: filing issues, submitting pull requests, and following repository activity across the federated network without requiring accounts on each instance.

This is genuinely novel for code hosting. GitHub and GitLab are silos — you need a GitHub account to interact with GitHub repositories and a GitLab account to interact with GitLab repositories. Forgejo federation would allow a developer with an account on their company's Forgejo instance to submit a pull request to an open source project hosted on Codeberg (a public Forgejo instance) without creating a Codeberg account. For the open source community specifically, this is a significant improvement over the current fragmented landscape.

Federation also has data sovereignty implications for organizations. Teams that self-host Forgejo can participate in the open source ecosystem without requiring their developers to create accounts on GitHub or GitLab. Contributors can interact with external projects through their company-controlled identity on the company's Forgejo instance. This is a governance and security benefit that doesn't exist in any alternative Git hosting model.

Gitea has no equivalent federation roadmap. This is the clearest reason to choose Forgejo if you're thinking about long-term platform evolution. The federation work is ongoing — ActivityPub federation for Forgejo is being implemented incrementally, with basic federation already functional in some preview builds as of early 2026. Teams setting up new Git infrastructure in 2026 with a multi-year horizon should weight Forgejo's federation trajectory heavily in the decision.

The resource efficiency of both platforms relative to GitLab is significant enough to shape infrastructure decisions beyond just the hosting cost. GitLab Community Edition, fully loaded, requires 4 GB RAM at minimum and performs better with 8 GB. Gitea and Forgejo run comfortably on 512 MB RAM for small teams, and under 1 GB for teams with dozens of active repositories. This means you can run either platform on the smallest tier VPS from any major provider ($4-6/month) alongside other services. GitLab effectively requires a dedicated server to function well. For teams where infrastructure cost is a real constraint, this 8:1 RAM efficiency ratio translates directly to dollars.

LDAP and OIDC integration deserves more attention for teams deploying in a corporate environment or alongside an identity management system. Both Gitea and Forgejo support LDAP, Active Directory, and OIDC providers natively. If you're running Authentik or Keycloak as a central identity provider (covered in the broader best open source alternatives to 1Password 2026 context for teams thinking about secrets management), connecting your Git hosting to SSO takes under 30 minutes and lets you manage access control centrally. Users authenticate with their SSO credentials rather than a separate Git account, teams are managed in one place, and offboarding a departing team member automatically revokes their Git access along with their other systems access.

---

See all open source developer tools at OSSAlt.com/categories/developer-tools.