Skip to main content

Gitea vs Forgejo vs GitLab Self-Hosted 2026

·OSSAlt Team
giteaforgejogitlabself-hostedgitci-cd
Share:

Gitea vs Forgejo vs GitLab Self-Hosted 2026

TL;DR

For self-hosted Git in 2026, the choice comes down to scale and philosophy. Gitea and Forgejo are nearly identical lightweight forges that run on a Raspberry Pi — the difference is governance (company vs. community non-profit) and license (MIT vs. GPL-3.0). GitLab CE is a full DevOps platform that requires 4–8GB RAM minimum but includes native CI/CD, security scanning, container registry, and more. For most teams under 50 people who just need solid Git hosting with basic CI, Forgejo is the recommendation. For teams who need the full GitLab feature surface without the SaaS cost, GitLab CE is worth the heavier footprint.

Key Takeaways

  • Gitea: MIT, ~44K stars, Go — original lightweight forge, largest third-party ecosystem
  • Forgejo: GPL-3.0, ~10K stars, Go — community fork of Gitea, non-profit governed, building ActivityPub federation
  • GitLab CE: MIT, ~24K stars, Ruby/Go — full DevOps platform, 4GB RAM minimum (8GB+ recommended)
  • Fork history: Forgejo split from Gitea in October 2022 after a for-profit company acquired the project without community consent
  • Hard fork: Since early 2024, Forgejo is a hard fork — migrations between them may diverge on future versions
  • GitLab gap: 10–40x more resources than Gitea/Forgejo but covers CI/CD, container scanning, epics, and roadmaps natively

Background: The Forgejo Split

In October 2022, the Gitea project's domains and trademark were quietly transferred to a for-profit company, Gitea Ltd., without community knowledge or approval. Developers who had contributed to Gitea under the assumption it was a community project wrote an open letter objecting. When the company confirmed the direction, a group of core contributors forked the project as Forgejo, placing it under the governance of Codeberg e.V., a German non-profit.

Initially Forgejo was a "soft fork" — functionally identical to Gitea, just with different governance and a more restrictive copyleft license (GPL-3.0 vs MIT). In February 2024, Forgejo formally announced it would become a hard fork, meaning its codebase would diverge from Gitea with features like ActivityPub federation that Gitea has no plans to implement.

This history matters for your decision: if you start on Gitea today, migrating to Forgejo in the future may not be a trivial upgrade once the codebases diverge further.

Feature Comparison Table

FeatureGiteaForgejoGitLab CE
LicenseMITGPL-3.0MIT
LanguageGoGoRuby + Go
GitHub Stars~44K~10K~24K
RAM (idle)100–200MB100–200MB4–8GB+
CI/CDGitea Actions (GitHub-compatible YAML)Forgejo Actions (GitHub-compatible YAML)GitLab CI/CD (native, extensive)
Container RegistryYesYesYes
Package RegistryYes (npm, PyPI, Maven, etc.)YesYes
Issue TrackerYesYesYes + Epics, Roadmaps
WikiYesYesYes
WebhooksYesYesYes
REST APIYesYesYes + GraphQL
LDAP/SSOYes (LDAP, OAuth)Yes (LDAP, OAuth)Yes (LDAP, SAML, OAuth, Kerberos)
Mirror reposYes (GitHub, GitLab, etc.)YesYes
Security scanningNoNoSAST, DAST, dependency scan
ActivityPub/FederationNoIn developmentNo
GovernanceGitea Ltd. (company)Codeberg e.V. (non-profit)GitLab Inc.
Self-hosted freedomHigh (MIT)Highest (GPL, non-profit)High (MIT)

Resource Requirements

Gitea and Forgejo

Both Gitea and Forgejo have almost identical resource profiles — they share the same codebase for most functionality.

  • Minimum: 512MB RAM, 1 CPU core (handles personal projects and small teams)
  • Comfortable: 1–2GB RAM, 2 CPU cores (teams of 10–30)
  • With Actions runners: Add 1–2GB RAM per concurrent runner

A $6/month VPS (2 vCPU, 2GB RAM) runs Forgejo comfortably for a team of 20. A Raspberry Pi 4 handles solo or small team use.

GitLab CE

GitLab's resource requirements are substantially higher due to its monolithic architecture running multiple services (Puma, Sidekiq, Gitaly, PostgreSQL, Redis, and more).

  • Minimum: 4GB RAM, 4 CPU cores (2 cores absolute minimum, degraded performance)
  • Recommended for 100 users: 8GB RAM, 8 vCPU
  • Recommended for 1,000 users: 16GB RAM, 8 vCPU
  • CI/CD runners: Separate machines recommended; each concurrent job adds ~500MB–2GB RAM

GitLab can be made to run in 2GB RAM with careful configuration (memory_constrained_envs settings) but this is not suitable for production use.

Docker Compose

Gitea

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    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=gitea
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - db

  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=gitea
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - ./postgres:/var/lib/postgresql/data

Forgejo

Forgejo uses the same Docker Compose structure — just swap the image:

    image: codeberg.org/forgejo/forgejo:latest

Everything else is identical. This is the "soft fork" benefit that still exists today.

GitLab CE

version: '3.6'

services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    container_name: gitlab
    restart: always
    hostname: 'gitlab.yourdomain.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.yourdomain.com'
        gitlab_rails['gitlab_shell_ssh_port'] = 2222
        # Reduce memory usage for smaller servers
        unicorn['worker_processes'] = 2
        postgresql['shared_buffers'] = "256MB"
    ports:
      - '80:80'
      - '443:443'
      - '2222:22'
    volumes:
      - './gitlab/config:/etc/gitlab'
      - './gitlab/logs:/var/log/gitlab'
      - './gitlab/data:/var/opt/gitlab'
    shm_size: '256m'

Note: GitLab CE takes 3–5 minutes to start on first boot as it initializes all services. Check docker logs gitlab for progress.

CI/CD Comparison

Gitea Actions and Forgejo Actions

Both implement GitHub Actions-compatible YAML syntax. If you have existing GitHub Actions workflows, they will largely work without modification. Runners use the same act_runner tool.

# .gitea/workflows/build.yml (works identically as .forgejo/workflows/build.yml)
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci && npm test

Limitations compared to GitLab CI: no built-in caching (must configure S3/MinIO), no native container scanning, no parallel matrix jobs across multiple runners without manual setup.

GitLab CI/CD

GitLab's CI/CD is more mature and built into the platform. Native features include:

  • SAST (static application security testing)
  • DAST (dynamic application security testing)
  • Dependency scanning
  • Container image scanning
  • Multi-stage pipelines with artifacts
  • Environment deployments with rollback
  • Review apps
  • Value stream analytics

For teams doing serious DevOps work, the GitLab CI/CD feature set justifies the resource cost.

Migration Paths

Gitea → Forgejo

Currently straightforward: Forgejo accepts Gitea database backups directly. Long-term, as the hard fork diverges, this path may require migration tooling.

Forgejo → Gitea

Same process in reverse, but moving from GPL to MIT means you're giving up governance protections. Data format is identical at present.

Gitea/Forgejo → GitLab CE

GitLab provides a migration tool that imports from Gitea via API:

  1. In GitLab, go to New Project → Import Project → Gitea
  2. Enter your Gitea URL and personal access token
  3. Select repositories to import (includes issues, PRs, milestones)

The import handles code, issues, pull requests, milestones, and labels. CI/CD pipelines must be manually converted from GitHub Actions YAML to GitLab CI YAML (the syntax differs).

GitLab CE → Gitea/Forgejo

No official migration tool from GitLab to Gitea. The Gitea community maintains an unofficial migration script for basic repository data. Issues, CI/CD pipelines, and container registry content require manual work.

When to Choose Each

Choose Gitea if:

  • You need maximum third-party tool compatibility (VS Code extensions, CI integrations, bots)
  • MIT license is important for your organization's legal requirements
  • You want the widest plugin ecosystem
  • You're already on Gitea and the governance change doesn't concern you

Choose Forgejo if:

  • You want community-governed, non-profit infrastructure
  • GPL-3.0 copyleft licensing aligns with your philosophy
  • You're interested in ActivityPub federation for cross-instance collaboration
  • You're starting fresh with no existing Gitea investment
  • You run Codeberg.org or want to align with that community

Choose GitLab CE if:

  • You need integrated CI/CD without managing separate runner infrastructure
  • Security scanning (SAST/DAST) is a hard requirement
  • Your team is 20+ and benefits from epics, roadmaps, and advanced project management
  • You're migrating from GitLab SaaS to cut costs
  • You can dedicate 8+ GB RAM to the server

For more on self-hosted Git options, see our guide to self-hosting Forgejo and the best open source GitHub alternatives. If you're evaluating the full self-hosted stack, the homelab software stack guide covers how Git hosting fits with CI/CD, container registries, and monitoring.

Security Considerations

All three platforms handle source code, which is typically among the most sensitive assets in an organization. Each has different security postures worth understanding.

Gitea and Forgejo have a smaller attack surface by design. Fewer services mean fewer vulnerabilities. Both projects release security patches promptly and maintain security advisories. The MIT and GPL-3.0 licenses both allow full code auditing. Running on a private network behind a reverse proxy with fail2ban for SSH brute-force protection is sufficient for most teams.

GitLab CE has more security features built in (secret detection, dependency scanning, SAST) but also a larger attack surface. The Omnibus package bundles dozens of services, any of which could have vulnerabilities. GitLab's security team is large and responsive — CVEs are typically patched within days — but you must stay current with updates. GitLab strongly recommends enabling two-factor authentication for all admin accounts and using instance-level webhook allowlists to prevent SSRF attacks.

For any of the three, the most important security practices are: TLS everywhere (Let's Encrypt via Certbot or Caddy), SSH key authentication only (no password auth), regular backups, and keeping Docker images updated.

Ecosystem and Integrations

Gitea's ecosystem advantage is real and measurable. Because Gitea has been around longer and has a larger user base, many third-party tools have native Gitea integration: VS Code extensions for PR reviews, bots for automatic labeling, migration tools from GitHub, and CI integrations. If you're using tools like Renovate (dependency update bot), Backstage (developer portal), or external CI services like Woodpecker CI, check their Gitea compatibility before committing.

Forgejo's compatibility is high today because the API is still largely identical to Gitea's. Most Gitea-compatible tools work with Forgejo. The divergence in APIs will increase as the hard fork matures, and tool vendors may prioritize Gitea compatibility over Forgejo's newer APIs.

GitLab's ecosystem is the largest, with native integrations for Kubernetes, Terraform, Vault, ArgoCD, and most major CI/CD and DevOps tools. If your organization uses enterprise tools like ServiceNow, Jira, or Salesforce, GitLab has official integrations. The tradeoff is that these integrations are more complex to configure and more likely to break on self-hosted instances after upgrades.

Hosted Alternatives

If managing your own Git server feels like too much overhead, several commercial and community-hosted options exist:

  • Codeberg.org: Forgejo-based, community-run, free for open source projects. The reference deployment of Forgejo.
  • Gitea.com: The hosted version of Gitea, maintained by Gitea Ltd.
  • GitLab.com: GitLab's SaaS offering, free tier available with 5GB storage and shared runners.
  • Sourcehut (sr.ht): Minimalist approach, git-first, open source, paid plans.

For teams that want the self-hosted control but not the ops burden, managed Gitea/Forgejo hosting providers exist on platforms like DigitalOcean Marketplace and Hetzner's App Platform.

Methodology

  • Sources consulted: 8
  • GitHub star data from GitHub.com, March 2026
  • Resource requirements from official documentation and community benchmarks
  • Forgejo governance history from forgejo.org and LWN.net coverage
  • Date: March 2026

Comments

Get the free Self-Hosting Migration Guide

Complete guide to migrating from SaaS to self-hosted open-source — infrastructure, data migration, backups, and security. Plus weekly OSS picks.

No spam. Unsubscribe anytime.