I replaced GitHub with a free, self-hosted alternative. Here's what I gained and lost

Published Nov 15, 2026, 7:00 AM EST Arol is a tech journalist who currently works as a contributor at How-To Geek since 2022. He first began writing online for the short-lived portal of Spanish-language gaming forum Emudesc in 2013. Years later, in 2017, he got his true start in tech journalism working for a small Google-focused site called Pixel Spot. He transitioned to a news and feature writer role at XDA Developers that same year, where he worked until 2021 before making the jump to other websites. Arol brings nearly a decade of writing experience, and the occasional hot take, to his writings. While he's a technology lover at heart, he holds computer hardware and smartphones particularly close to heart. You'll normally find him covering news, although he has also written the occasional deal, buyer's guide, how-to post, and round-up. He's also written for Android Police and MakeUseOf. He's also a Political Science student at the Central University of Venezuela, and a proud member of student movement Àgora UCV. When he's not writing, you'll probably find him hitting the gym, trying to ace a new hobby, reading his textbooks, or traveling. You can reach him at me@arolwright.com. Sign in to your How-To Geek account GitHub has become the default home for countless software projects, but I wanted more control over where my repositories lived and how they were managed. That led me to Forgejo, an open-source Git hosting platform I could run on my own hardware. That led me to Forgejo, an open-source Git hosting platform I could run on my own hardware. Moving away from GitHub gave me greater independence, but it also introduced maintenance responsibilities and trade-offs I hadn't fully anticipated. But how do you actually pull this off? Be the keeper of your own code To understand what Forgejo even is in the first place, you first need to know that it’s a Git forge that you run yourself. Its origins help explain its community-focused approach. It started life in December 2022 as a fork of Gitea. Things changed when a for-profit company — run by Gitea’s main maintainer — took over the trademarks and operations. While it stayed pretty close to Gitea initially, it eventually became a hard fork in early 2024, and the two codebases have been diverging ever since. Today, it stands as its own independent project, with its own release cycle, documentation, and priorities. Forgejo is relatively lightweight for a Git hosting platform. Forgejo gives you everything you need — repositories, pull requests, issue tracking, CI/CD, and even a package registry — all running on hardware that you own, using roughly 100MB of RAM. Since it’s written in Go, it ships as a single binary and comes with an official container image, meaning it can run on a range of hardware from an old laptop to a mini PC or a single-board computer. You can get a fully working instance with a simple Docker Compose file using just one service and a data volume. For a solo user, the built-in SQLite option is sufficient for many small deployments, but if multiple people are going to be using the server at once, PostgreSQL is the way to go. The more involved work comes from configuring the surrounding infrastructure. For an internet-facing instance, you'll typically want a domain name, HTTPS, and a secure way to access Git repositories. A reverse proxy such as Caddy or Nginx can handle HTTPS, while SSH is an option for Git operations. Local-only installations can be simpler, although they still require appropriate security measures. Moving your repos over is Forgejo’s biggest selling point. Forgejo's migration tools can import Git repositories and much of their associated project data, including issues, pull requests, labels, milestones, and releases. However, not every GitHub feature or piece of metadata transfers perfectly, so it's worth checking the imported repository before retiring the original. For private repositories, you just need to give it a GitHub personal access token and select which pieces you want to migrate. If you aren't ready to cut the cord completely, you can set up the repo as a mirror instead. Forgejo can maintain a pull mirror that periodically fetches changes from GitHub. This keeps the repository's Git content synchronized in one direction, but it doesn't provide full two-way synchronization of issues, pull requests, and other project features. It’s a smart way to run both side by side while you get settled. The advantages Control, openness, and a lean, community-focused forge The biggest benefit is control over your infrastructure — and with Forgejo, that control goes deeper than just owning the server. Now, my code, my issue history, and my release records all live on a disk I can physically see, back up, and move. I no longer depend on a hosting provider's changing service terms, or reshape the product around corporate priorities that I don't share. That feeling of control extends right down to the project itself. Forgejo is managed under Codeberg e.V., a registered German non-profit that holds the domain names and trademarks. Crucially, it re-licensed from MIT to GPL v3+ starting with v9.0. There is no "proprietary edition" and no copyright assignment for contributors. Forgejo's GPLv3-or-later licensing and nonprofit governance help ensure that its released code remains available under open-source terms. Unlike platforms that reserve certain features for paid editions, Forgejo currently focuses on providing its functionality through a community-developed codebase. Plus, Codeberg runs its own public forge on Forgejo, meaning the people who run it are heavy users of what they champion, which tends to keep the priorities grounded and focused on the community. On a day-to-day basis, Forgejo is pleasantly unremarkable. And I don't mean that in a bad way. The interface is familiar enough that navigating repositories and issues requires little adjustment. You have the repos, pull requests, issues, labels, milestones, a wiki, a releases page, and a package registry — all right there. The practical limits are simply what your hardware allows. There's no "storage upgrade" menu or limited CI minutes to ration, because the runners are yours. Forgejo Actions turned out to be better than I expected. It adopts GitHub’s YAML syntax, and if you don't have a dedicated .forgejo/workflows directory, it knows to look in .github/workflowsso simple build-and-test pipelines won't break just because you moved them. Recent releases have kept investing in this area too. For example, Forgejo v15.0 shipped on April 16, 2026, for the project’s 100th release, adding things like repository-scoped tokens, OIDC support, and ephemeral runners. And finally, there’s stability on my schedule. Forgejo’s 15.0 branch is an LTS release supported through July 15, 2027. This means I can stick to a long-term release and upgrade when I genuinely decide to, not when some vendor decides to ship a radical redesign. The (many) disadvantages You become the operations team and lose the crowd Running Forgejo means you are instantly its full-time operations team, which is a given, really, if you're going to self-host basically anything. The project moves fast, with a major new version coming out roughly every quarter, and non-LTS branches have short lifespans. Security updates pop up in between, and while Forgejo does publish advance warnings, that only helps if you are actively paying attention. Backups are your job too. If your disk dies before you’ve set up proper backups, there isn’t a support ticket to file. And "free" needs a huge asterisk — because while the software costs nothing, the hardware, the electricity, and the domain name certainly do. If you're doing external hosting, that's gonna cost you, too. Forgejo Actions is more complex than the familiar syntax suggests. The documentation is clear: it is designed to feel familiar to GitHub Actions users, not to be fully compatible. Be ready for some minimal tweaking when you migrate a workflow. Also, workflows don't run on the Forgejo instance itself. They are handed out to separate runners, meaning you have to install and maintain the separate Forgejo Runner, and builds consume resources on your own runners. If your pipelines rely on GitHub-specific actions or hosted macOS/Windows runners, expect additional configuration or workflow changes The biggest drawback, though, is the network effect. Over 180 million developers now use GitHub, according to its Converse 2025 report. Although visitors can browse and clone public repositories without an account, contributing through issues or pull requests generally requires authentication. On a personal Forgejo instance, that adds friction for developers accustomed to using their existing GitHub accounts. Forgejo’s federation work is trying to fix this, but it’s still a work in progress and isn't a magic substitute for simply being where everyone already is. Old links suffer, too. When Organic Maps moved to Forgejo, its GitHub repository had to become a mirror, which disabled the issue tracker and wiki. This broke old links from other repositories, forums, and the OSM Wiki, forcing users to manually re-subscribe to any issues they had been following. Expect a smaller universe of integrations, too, because far fewer third-party tools target Forgejo’s API compared to GitHub’s. Forgejo gives you ownership, but it demands constant upkeep. Moving to Forgejo gave me greater control over my repositories, project data, and hosting infrastructure — a lean, non-profit, copyleft forge, and CI running on my own terms. But it also made me the sysadmin, and it cut me off from the massive audience that GitHub provides. For personal side projects, that trade works beautifully. But for community projects, you need to think twice.