GitHub is the default home for open-source code. Millions of developers use it every day, and for good reason. It provides excellent tools for collaboration, issue tracking, pull requests, and automation.
For many years, I used GitHub as the center of my development workflow. It worked well and I still keep some public repositories there.
But over time something started to bother me. My entire development workflow depended on a platform I did not control.
As my personal infrastructure grew and my focus shifted toward privacy and data ownership, I started exploring alternatives. Eventually I decided to migrate my projects to a self-hosted Git server using Gitea.
This article explains why I made that decision, what I gained from it, and the trade-offs involved in running your own Git hosting platform.
Backstory
I have used GitHub for years and still maintain some public repositories there. A few of them have collected community stars.
GitHub is extremely convenient. You sign up, push your code, and everything just works.
However, as I started building more self-hosted infrastructure, I began thinking differently about where my code lives.
Code is one of the most valuable things a developer creates. It represents ideas, experiments, and sometimes years of work. Storing that entirely on a third-party platform began to feel uncomfortable.
That led me to ask a simple question:
What would it look like if I hosted my own Git platform?
The Primary Motivator: Data Sovereignty
The main reason I moved away from GitHub was data ownership.
When your repositories are hosted on a centralized platform, you rely on that company’s policies, infrastructure, and long-term decisions.
Most of the time this works fine. But it also means you do not have complete control.
The Rise of AI and Code Licensing
In recent years, source code has become extremely valuable as training data for large language models.
Tools like GitHub Copilot are useful, but they also raised new questions about how public code is used and indexed.
Even though GitHub provides ways to opt out of certain training programs, centralized platforms can change policies over time.
By hosting my own Git server, I know exactly where my repositories live and how they are used.
Private repositories stay private.
No external platform has access to them.
Avoiding Platform Dependency
Another concern is platform dependency.
GitHub is owned by Microsoft and is unlikely to disappear anytime soon. But relying entirely on a single provider still introduces risk.
Terms of service can change. Features can be removed. Prices can increase.
There have also been moments when GitHub experienced outages that affected developers worldwide.
Running my own Git server removes those external dependencies.
My repositories live on my own infrastructure.
Why I Chose Gitea
When looking for a GitHub alternative, there are several options available.
Some of the most popular ones include:
GitLab is extremely powerful, but the self-hosted version can be heavy and resource-intensive.
Forgejo is a strong community-driven fork of Gitea and an excellent project, but for my use case I preferred the slightly broader ecosystem around Gitea.
Gitea turned out to be the best balance.
It is lightweight, easy to deploy, and provides almost everything I used on GitHub.
What Is Gitea?
Gitea is an open-source Git hosting platform written in Go. It provides a web interface for managing repositories, issues, pull requests, and automation pipelines.
In many ways it feels very similar to GitHub, but it runs entirely on your own server.
Some key features include:
- Repository hosting
- Issue tracking
- Pull requests
- Wiki support
- CI/CD with Gitea Actions
- Container registry
- Organization and team management
Despite being lightweight, it covers almost every feature I need for personal development projects.
My Self-Hosted Setup
One of the biggest advantages of Gitea is that it runs well on very small servers.
My setup is intentionally simple.
PROXMOX
└── LXC Container
└── Gitea
├── PostgreSQL
├── Actions Runner
└── Container Registry
The container runs on a small virtual private server with modest resources.
Typical usage looks like this:
1 CPU core512 MB RAMvery low idle usage
Even on this small configuration, the interface feels fast and responsive.
Because Gitea is written in Go, the memory footprint is small compared to many other platforms.
Features That Replaced GitHub for Me
After migrating, I was surprised by how little I actually missed from GitHub.
Repository Management
Gitea provides the core Git features you expect:
- commits
- branches
- pull requests
- issue tracking
The workflow feels very familiar.
Built-in CI/CD
Gitea Actions is similar to GitHub Actions and supports automated workflows.
This allowed me to run build pipelines and tests directly inside my self-hosted environment.
Container Registry
One feature I particularly like is the built-in container registry.
Instead of pushing Docker images to Docker Hub, I now store them directly inside my Gitea instance.
This keeps my entire development pipeline under my control.
Organizations and Access Control
Gitea also supports organizations and team permissions, making it easy to manage access to repositories.
Migrating From GitHub to Gitea
I expected migration to be difficult.
It turned out to be surprisingly simple.
Gitea provides a built-in migration tool. You only need to provide the GitHub repository URL and your authentication token.
Gitea can import:
- repository history
- issues
- pull requests
- releases
- wiki content
I migrated dozens of repositories in a single afternoon.
After that, the only manual step was updating my local Git remotes.
Example:
git remote set-url origin https://git.imapdr.com/hyper4saken/repository_name.git
Once that was done, development continued normally.
The Trade-Offs of Self-Hosting
Self-hosting is not perfect.
Convenience is one of the main advantages of platforms like GitHub.
When you run your own infrastructure, you take on additional responsibilities.
Maintenance
I now handle tasks that GitHub previously managed:
- operating system updates
- database maintenance
- container upgrades
- Backups
Reliable backups are essential.
I use automated backups with Restic to store encrypted snapshots of my repositories.
Monitoring and Uptime
If the server goes down, it is my responsibility to fix it.
To keep track of availability, I monitor my services using uptime monitoring tools.
Self-hosting requires more attention, but it also provides full control.
When Self-Hosting Git Makes Sense
Running your own Git server is not necessary for everyone.
It makes the most sense if you:
- already manage servers
- care about data ownership
- want full control over your infrastructure
- prefer open-source tooling
If you just want a place to host code quickly, GitHub is still an excellent choice.
Final Thoughts
Moving from GitHub to a self-hosted Gitea server was ultimately about ownership.
GitHub provides incredible tools, but it also means trusting a third-party platform with your code and development workflow.
By running my own Git server, I control the infrastructure, the data, and the policies that govern it.
The trade-off is additional responsibility. I now manage backups, updates, and uptime myself.
For me, that trade-off is worth it.
If you are already comfortable running servers and value independence, self-hosting your Git platform can be a very rewarding step.