{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifqfq5uu4636okdhwgiw7ngmqgkhjzfhvg2frnr3otyk7fwznuhva",
    "uri": "at://did:plc:yaz3p6kpjacwypalo2scppxc/app.bsky.feed.post/3moft4njbdsx2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidxkz5uqwvfp2a46tlqhlxickvvzxbxyh4nrazwtan3lo7r6gniqa"
    },
    "mimeType": "image/png",
    "size": 115881
  },
  "description": "Gitea is the lightweight self-hosted GitHub alternative — single Go binary, 55k+ stars, GitHub Actions compatibility, runs on a Raspberry Pi. There's also Forgejo, its community fork that many now recommend instead. Here's what both are and when to pick which.",
  "path": "/gitea-forgejo-self-hosted-github-alternative/",
  "publishedAt": "2026-06-16T12:42:02.000Z",
  "site": "https://devopspack.com",
  "tags": [
    "Get in touch at pipoline.com →"
  ],
  "textContent": "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.\n\nGitea 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.\n\n## What Gitea is\n\nGitea 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.\n\nIt'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.\n\nThe feature set covers everything a development team actually needs day-to-day:\n\n  * **Git hosting** — repositories, branches, tags, releases, Git LFS\n  * **Code review** — pull requests with inline comments, review requests, protected branches\n  * **Issues and projects** — issue tracker, milestones, labels, kanban-style project boards\n  * **Gitea Actions** — CI/CD using the same YAML syntax as GitHub Actions, with the open source `act_runner` executor\n  * **Container registry** — Docker image hosting built in, no separate registry required\n  * **Package registry** — npm, PyPI, Maven, NuGet, Cargo, Helm, and more\n  * **Wiki** — per-repository wikis backed by Git\n  * **Webhooks and API** — REST API covering all resources, compatible with many GitHub API clients\n  * **OAuth2 and LDAP** — sign in with GitHub, Google, GitLab, or any OIDC provider; LDAP/Active Directory integration\n\n\n\n## The Forgejo fork — and why it matters in 2026\n\nIn 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.\n\nThis matters because Forgejo and Gitea have diverged in meaningful ways since the fork:\n\n  * **License** — Forgejo uses GPL v3 (copyleft), Gitea uses MIT. For organizations with procurement policies around copyleft, this matters.\n  * **Governance** — Forgejo has an elected council, public roadmap discussions, and no commercial entity. Gitea has a company (Gitea Limited) that makes decisions.\n  * **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.\n  * **Forgejo Actions** — shipped GitHub Actions compatibility before Gitea Actions did. Both now have it.\n  * **API compatibility** — both share the same database schema and API at the core, so migration between them is straightforward.\n\n\n\nThe 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.\n\n## Gitea Actions — the feature that removes the migration blocker\n\nThe 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.\n\nGitea Actions (and Forgejo Actions) uses the **same YAML syntax as GitHub Actions**. Many workflows migrate with minimal changes:\n\n\n    # .gitea/workflows/ci.yml (or .forgejo/workflows/ci.yml)\n    name: CI\n\n    on:\n      push:\n        branches: [main]\n      pull_request:\n\n    jobs:\n      test:\n        runs-on: ubuntu-latest\n        steps:\n          - uses: actions/checkout@v4\n          - name: Run tests\n            run: |\n              go test ./...\n              go build ./...\n\nThe 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.\n\nNot 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.\n\n## Self-hosting Gitea\n\nDocker Compose is the simplest production path. Gitea with PostgreSQL:\n\n\n    services:\n      gitea:\n        image: gitea/gitea:latest\n        container_name: gitea\n        restart: unless-stopped\n        environment:\n          USER_UID: 1000\n          USER_GID: 1000\n          GITEA__database__DB_TYPE: postgres\n          GITEA__database__HOST: db:5432\n          GITEA__database__NAME: gitea\n          GITEA__database__USER: gitea\n          GITEA__database__PASSWD: ${POSTGRES_PASSWORD}\n        volumes:\n          - ./gitea-data:/data\n        ports:\n          - \"3000:3000\"\n          - \"2222:22\"   # SSH clone port\n        depends_on:\n          - db\n\n      db:\n        image: postgres:16\n        restart: unless-stopped\n        environment:\n          POSTGRES_DB: gitea\n          POSTGRES_USER: gitea\n          POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}\n        volumes:\n          - ./postgres-data:/var/lib/postgresql/data\n\nFor Forgejo, replace `gitea/gitea:latest` with `codeberg.org/forgejo/forgejo:latest`. The rest is identical.\n\nPut 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.\n\nA few production considerations:\n\n  * **SSH port** — expose port 22 or 2222 for SSH cloning. Without it, users are HTTPS-only.\n  * **SMTP** — configure for email notifications, password resets, and user registration emails.\n  * **Storage** — Git LFS and package registry artifacts need persistent storage. Plan accordingly.\n  * **Backups** — the `gitea-data` volume and PostgreSQL database are what you need to back up. Simple, predictable.\n\n\n\n## Migration from GitHub\n\nGitea 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.\n\nAuthor 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.\n\nFor 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.\n\n## Gitea vs GitLab vs GitHub\n\n**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.\n\n**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.\n\nThe 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.\n\n## Who it's for\n\n**Good fit:**\n\n  * Teams who want GitHub-style code hosting on their own infrastructure without GitLab's operational overhead\n  * Organizations with data sovereignty requirements — source code can't live on GitHub or GitLab.com\n  * Small to medium engineering teams (1-50 developers) who want a complete Git platform without dedicated DevOps to maintain it\n  * Self-hosters who want Git hosting alongside their other self-hosted tools (Plane, Outline, Dokploy, etc.)\n  * Teams already on GitHub Actions who want to self-host CI/CD without rewriting workflows\n\n\n\n**Not the right fit:**\n\n  * Teams that need GitLab's advanced security scanning (SAST, DAST) — stick with GitLab\n  * Organizations that need the GitHub network effect for open source contributions\n  * Teams that need Gitea Enterprise features (SAML, advanced audit logs) on the free tier — those are paid\n\n\n\n## My take\n\nGitea 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.\n\nThe 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.\n\nFor 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.\n\n* * *\n\nPIPOLINE · DEVOPS CONSULTING\n\n### Need help setting up Gitea or Forgejo?\n\nGetting Gitea or Forgejo into production — Docker Compose, PostgreSQL, SSH configuration, Traefik for HTTPS, SMTP, act_runner for Actions, and migrating your repositories from GitHub — takes an afternoon to do properly. I can handle the full setup and migrate your existing repositories, issues, and CI/CD workflows. You get a production-ready self-hosted Git platform without the GitLab overhead.\n\nGet in touch at pipoline.com →",
  "title": "Gitea and Forgejo: Self-Hosted GitHub Alternative That Runs on a Raspberry Pi",
  "updatedAt": "2026-06-16T12:42:02.326Z"
}