Why I Use Both GitHub and Forgejo - And Why That Matters

Sat, 23 May 2026 00:00:00 +0000

The Setup

I use GitHub for my public projects. I share code there, participate in the community, open issues on other people’s repos, and let people discover my work. That part of my workflow is locked into GitHub — not because I love the company, but because that’s where the developers are. The network effect is real.

I also run Forgejo on my own hardware. Self-hosted. My rules, my servers, my data. No corporate oversight, no acquisition risk, no sudden policy changes from a company that answers to shareholders.

They look similar because they’re built on the same lineage. GitHub Actions and Forgejo Actions share the same YAML syntax, same runs-on: labels, same actions/checkout@v4 kind of steps. The only structural difference is where you put your workflow files: .github/workflows/ on GitHub, .forgejo/workflows/ on Forgejo. Sometimes .github/workflows/ works on Forgejo too, depending on your version and configuration.

I use both. Not because I am hedging my bets. Because they solve different problems.

What Forgejo Is

Forgejo is a self-hosted Git forge. It does the expected things well:

Repositories, pull requests, code review, and issue tracking
Wiki, package registry, releases
Repository mirroring — less talked about, extremely useful
Built-in CI/CD via Forgejo Actions (GitHub Actions-compatible)

Forgejo powers Codeberg, the non-profit code hosting platform. It’s developed under the umbrella of Codeberg e.V., a German non-profit whose entire mission is guaranteeing the openness and continued availability of free software. The license is GPLv3+ starting with v9.0 — a deliberate choice that prevents someone from taking the code, stripping it down, and selling it as a proprietary product without sharing their changes.

The people building it are volunteers, grant recipients, and donors through Codeberg’s Liberapay. No venture capital. No acquisition target. Just people who want a sustainable, community-controlled Git forge.

That is the story. The features are secondary.

The Feature That Actually Matters

Here is what I care about: Forgejo Actions lets me run CI on my own hardware using the same workflow syntax that GitHub uses.

My setup is a single Debian VM on my homelab, running two Forgejo runner instances via systemd template services. Each runner pulls Docker containers for ubuntu-latest jobs. The runners are lean — just enough cores and disk to chew through builds without complaining.

Workflows live in .forgejo/workflows/ in your repository. They work just like GitHub Actions. Write the YAML, push, and the runner picks it up.

This is the practical bridge between the two platforms. I can write a workflow once, adapt it slightly, and run it on my own hardware with zero GitHub dependency. The syntax is familiar because Forgejo Actions was built on act, the open-source project that runs GitHub Actions locally. It’s designed to be familiar, not identical — the Forgejo team has said they don’t plan to chase GitHub’s changes. That’s intentional. They want users to feel comfortable, not locked in.

My daily use:

Automating Docker image builds
Running tests on code changes
Handling deployments across my homelab
Mirroring public GitHub repos to my Forgejo instance for backup

The mirroring is worth calling out. I use it for some of my projects — push to GitHub, mirror to Forgejo. The .forgejo/workflows folder is ignored on GitHub, but the .github/workflows folder on Forgejo can be configured to work too (depending on your version). It’s not a perfect one-way sync, but it’s good enough for what I need.

Why Not Just Use GitHub

Two words: vendor lock-in.

GitHub is a fantastic product. But it is also a for-profit company owned by Microsoft. Their pricing changes. Their policies change. Their AI features eat into your private code. Their terms of service are not something you control.

When you build your CI/CD around GitHub Actions, you are building on rented land. You can migrate — it’s not impossible — but it is painful. Every workflow file references GitHub’s APIs, GitHub’s runner images, GitHub’s marketplace. You are tied to their ecosystem.

Forgejo removes that dependency. Your CI runs on your network, with your hardware. Credentials, artifacts, logs — everything stays local. Want more concurrency? Spin up another runner. Need a heavier build environment? Give the VM more RAM. You are not paying per minute to a cloud provider, and you are not at the mercy of a vendor’s pricing page.

Why Not Just Use Forgejo

Because I want people to find my work.

GitHub is where the open source community lives. People file issues, submit pull requests, star repos, fork projects. If you want your code to be discovered, used, and contributed to, GitHub is still the place to be. The network effect is not a marketing claim — it’s a measurable reality. Most open source projects live on GitHub because that’s where the developers already are.

Forgejo is excellent for private projects, for code you want to control, for infrastructure you want to own. But it is not a community platform. There is no “trending” page. No discovery mechanism. No way for a random developer to stumble across your project and submit a pull request.

Running both is not redundancy. It’s strategy.

The Workflow

Here is how it actually works in practice:

Public repos live on GitHub. I use .github/workflows/ for CI. People discover my work, file issues, submit PRs.
Mirror repos go to my Forgejo instance. The mirror keeps a copy safe on my hardware.
Private repos live on Forgejo. .forgejo/workflows/ for CI. No GitHub dependency.
Forgejo Actions can often reuse GitHub Actions workflow files with minimal changes. The syntax is the same. The runner is different. The YAML is familiar.

Forgejo’s mirroring feature makes this frictionless. Set it up once, and your GitHub repos are automatically synced to your self-hosted instance. You get a backup that runs its own CI, independent of GitHub’s infrastructure.

The Culture Question

This is the part that actually matters.

Gitea and Forgejo are basically the same product. Same codebase lineage, same feature set, same UI. The difference is not technical — it’s cultural.

Gitea’s lead maintainer founded a for-profit company, transferred trademarks, and started pushing toward an open-core model with a hosted SaaS product. The code stayed open source — technically — but the direction felt off. Long-time maintainers left. Trust broke.

Forgejo started as a soft fork of Gitea in December 2022, then went hard fork in early 2024. The people who left Gitea decided they would rather build something where the project’s governance matched its stated values. Forgejo runs under Codeberg e.V., a German non-profit. GPLv3+ license. No acquisition target. No SaaS push.

I care about that. Not because I am some open-source purist with a sign outside my door, but because I am building infrastructure I expect to still be here in three years. Long-term stability is not a nice-to-have for homelab gear. It is the whole damn point.

The Bottom Line

If you are building infrastructure you want to own, run Forgejo. If you want your code to be discovered and contributed to by the open source community, use GitHub. Running both is not a compromise — it is the best of both worlds.

I am not saying Forgejo is perfect. The federation features are experimental right now. The documentation is good but still catching up to the velocity of the code. And the ecosystem of community actions is not as large as GitHub’s — though the default Actions URL points to , which has the essentials.

But for what I need — a reliable, self-hosted Git forge with proper CI/CD that I know will still be around when my next homelab upgrade cycle hits — Forgejo is the right call.

GitHub for community. Forgejo for control. Both using the same workflow syntax. That is not redundancy. That is a strategy.

Forgejo is a project under Codeberg e.V. Their site is at , source code lives on , and you can support them via .

— self-hosted infrastructure that benefits from the same Git server, with real network hardening practices.
— another self-hosted Git option, lighter weight than Forgejo.

Forgejo | Derek Armstrong — Software Engineer · AI · Infrastructure