Self-Hosting Your Git Forge: A Practical Guide for Data Sovereignty

At Dumontix, we work exclusively with European cloud providers. This isn’t a marketing gimmick or a philosophical stance we adopted because it sounded good; it’s a practical requirement for many of our clients. When you’re handling data for European companies, particularly those in regulated industries, “just use GitHub” isn’t always an option. Sometimes your code, your issues, your CI/CD pipelines, and your deployment secrets need to stay within jurisdictional boundaries that you can actually verify.

We’ve spent years building expertise around Scaleway, Hetzner, OVH, and other European infrastructure providers. We know their quirks, their pricing models, their support response times. We know which ones have the best block storage performance and which ones you should avoid for latency-sensitive workloads. This specialization means we sometimes have to solve problems that would be trivial if we could just point clients at a US-based SaaS solution.

Git hosting is one of those problems.

The Tutorial That Became a Project

This whole thing started as a blog post. I was going to write a nice tutorial: “How to Deploy Forgejo on Scaleway in 30 Minutes.” I had the Terraform configs, a few Ansible tasks, some notes about Let’s Encrypt and reverse proxies. It was going to be straightforward.

Then I started writing, and the edge cases piled up. What about backups? What about updates? How do you handle the database-containerized or on the host? What happens when someone wants to use Hetzner instead of Scaleway (this is our provider so I wrote it originally for their case)? Do you provision storage separately or use the boot disk? How do you manage secrets without committing them to the repository you’re trying to self-host?

By the time I had addressed all these questions, I wasn’t writing a tutorial anymore. I was building infrastructure-as-code that I’d actually want to use in production. So I stopped pretending it was a blog post and turned it into a proper project.

The result is forgejo-autohebergement, a complete toolkit for deploying Forgejo on European cloud providers. It handles infrastructure provisioning with Terraform, server configuration with Ansible, automated backups, HTTPS certificates, firewall rules, and even VPN-based SSH access. You can have a production-ready Git forge running in under an hour, and more importantly, you can understand and modify every piece of it.

Eating Our Own Ops-flavoured Cookies.

The Forgejo instance at git.dumontix.eu runs on this exact template. We made a few tweaks based on our preferences: different log retention periods, some additional monitoring hooks, a slightly more aggressive backup schedule; but the core is identical to what you’ll find in the public repository.

This isn’t just dogfooding for the sake of credibility, more of a sharing our lunch situation instead. When we find a bug or need a new feature, we fix it in the same codebase our clients use. When Forgejo releases a new version, we update our instance first and then push the tested changes upstream. The template improves because we depend on it.

Our deployment uses Scaleway’s DEV1-S instances in Paris, with block storage for the data volume. PostgreSQL runs directly on the host rather than in a container-we prefer the operational simplicity and the ability to use standard Debian tools for database maintenance. Caddy handles TLS termination and reverse proxying, which eliminates an entire category of certificate renewal headaches that plagued our older nginx setups.

The Tailscale Question

One component in our stack isn’t European: Tailscale. We use it to secure SSH access to our servers, creating a zero-trust network where the management port is never exposed to the public internet.

This was a deliberate choice, and I want to be transparent about the reasoning. I know the founders from spending time in the Go community. I’ve watched them build the company and I trust their approach to security and privacy. When you’re choosing infrastructure components, the humans behind the project matter as much as the technical specifications.

That said, I acknowledge this creates a dependency on a US-based service. For clients with strict data residency requirements, we discuss alternatives. Headscale, the open-source Tailscale control server, is one option. Netbird is another. WireGuard directly, with your own key distribution, works fine if you’re comfortable managing it. The Ansible roles in our template are designed to be swappable-Tailscale is the default because it has the best developer experience, but the firewall rules and SSH configuration don’t assume any particular VPN solution.

Eventually, we’ll probably adopt a fully European alternative as the default. The ecosystem is maturing, and projects like Netbird are getting good enough for production use. For now, we’ve made a pragmatic choice that we’re comfortable explaining to clients (and, you have to pick your battles, you can fight them all but one at a time).

Why Forgejo?

I chose Forgejo over Gitea, GitLab, or other alternatives for a few reasons. It’s lightweight enough to run on minimal infrastructure: Our production instance uses a 2-vCPU, 2GB RAM server and barely notices the load. It’s actively developed by a nonprofit foundation with a clear governance model, which matters when you’re betting your source code on a project. And it has feature parity with what most teams actually need: pull requests, issues, CI integration via webhooks, container registries, and decent API coverage (I also like it).

GitLab is excellent but requires significantly more resources and operational complexity. For teams that don’t need its advanced CI/CD features or enterprise integrations, it’s overkill. Gitea would have been fine technically, but the governance situation made us uncomfortable. Forgejo emerged from the Gitea community specifically to address those concerns, and the project has proven itself stable and reliable.

How It Works

The deployment process has two phases. First, Terraform provisions the cloud infrastructure: a compute instance, a block storage volume, DNS records if you’re managing them through the provider, and the necessary firewall rules at the cloud level. Second, Ansible configures the server: installs dependencies, sets up PostgreSQL, deploys Forgejo as a Docker container, configures Caddy for HTTPS, establishes backup routines, and hardens the system.

A setup wizard guides you through the initial configuration:

./setup-wizard.sh

It asks for your cloud provider credentials, your domain name, and generates the necessary secrets. You can also configure everything manually if you prefer-the wizard just creates the same YAML files you’d write by hand.

The Makefile provides shortcuts for common operations:

make help              # Show all available commands
make install           # Full deployment from scratch
make deploy            # Update configuration
make backup            # Create a backup
make backup-cron       # Non-interactive backup for cron jobs
make ssh               # Connect to the server

Backups include the PostgreSQL database, all Git repositories, LFS objects, and Forgejo’s configuration. They can stay local on the server’s block storage or sync to S3-compatible object storage. Restoration is a single command that stops the service, replaces the data, and restarts everything.

Contributing Without Registration

Since git.dumontix.eu doesn’t allow public registration, we’ve set up a workflow for external contributions. There’s a synchronized mirror on Codeberg at codeberg.org/dumontix/forgejo-autohebergement. Contributors fork the mirror, make their changes and make a Pull Request to it. We review the changes and merge them with proper attribution.

It’s not as seamless as a pull request on a platform with open registration, but it works. Forgejo’s federation features will eventually enable cross-instance pull requests through the ForgeFed protocol-the specification is in development and early implementations are appearing. Until that’s production-ready, the fork-and-link workflow is a reasonable compromise.

Getting Started

If you want to run your own instance, clone the repository and run the wizard:

git clone https://codeberg.org/dumontix/forgejo-autohebergement.git
cd forgejo-autohebergement
./setup-wizard.sh

You’ll need accounts with your chosen cloud provider and a domain name pointing to where the server will live. The wizard handles the rest, including generating secure passwords and encryption keys.

The documentation covers provider-specific details, customization options, and operational procedures. If you run into problems, open an issue. If you make improvements, we’d love to see them.

Self-hosting isn’t for everyone. It requires ongoing maintenance, security awareness, and a willingness to debug problems at 2 AM when something breaks. But for organizations that need control over their source code infrastructure-whether for regulatory compliance, data sovereignty, or just philosophical preference-it’s entirely achievable. The tools have matured enough that you don’t need a dedicated platform team to run a reliable Git forge.

We’ve been running ours for a while now. It works.

–

If you feel this resonates with the challenges your company faces daily, talk to us and let’s see how we can help you