en

Anonymous Git Hosting with Gitea and Forgejo on .onion

Self-hosted Git platforms like Gitea and Forgejo give developers full control over their source code repositories without relying on centralized platforms that may comply with government takedown requests or expose contributor identities through IP logs. Deploying Gitea or Forgejo as a Tor hidden service creates an anonymous code collaboration environment where contributor identities remain protected and the repository location is obscured. This architecture is used by privacy-conscious development teams, open-source projects in restrictive jurisdictions, and security researchers who need to share code without attribution. Unlike clearnet Git platforms that expose SSH connection origins and web interface access logs, a .onion-hosted Gitea records no IP addresses by design. This guide covers the complete deployment pipeline from installation through SSH-over-Tor configuration, webhook routing, and repository access control for anonymous development teams.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

Choosing Between Gitea and Forgejo

Gitea and Forgejo are both lightweight, self-hosted Git services written in Go that run well on low-resource servers. Forgejo is a community fork of Gitea that emerged in 2022, offering a more community-governed development model with identical feature sets for most use cases. Both support issues, pull requests, wikis, CI/CD hooks, and SSH key authentication. For .onion deployment, either works identically - the choice depends on governance preferences rather than technical requirements. Gitea has broader third-party integration documentation while Forgejo has more active community governance. Both are available as single binaries, Docker images, and package manager installations. Resource requirements are minimal: 256MB RAM and 1 CPU core handles dozens of concurrent users and hundreds of repositories.

Base Server Configuration for .onion Git Hosting

Install Gitea or Forgejo on a server with Tor installed. Create a dedicated system user: useradd -r -s /bin/bash -d /home/git git. Download the binary from the official releases, place at /usr/local/bin/gitea, and set executable permissions. Create the working directory structure: /etc/gitea, /var/lib/gitea/{custom,data,log}, setting ownership to the git user. Configure /etc/gitea/app.ini with the critical setting DOMAIN = your56charsonionaddress.onion and ROOT_URL = http://your56charsonionaddress.onion. Disable external email registration if maintaining a private collaborative environment. Set SSH_LISTEN_PORT = 22 and SSH_DOMAIN = your56charsonionaddress.onion so SSH clone URLs are generated with the .onion address, not a clearnet hostname.

Configuring Tor for the Hidden Service

Add to /etc/tor/torrc: HiddenServiceDir /var/lib/tor/gitea/, HiddenServicePort 80 127.0.0.1:3000, HiddenServicePort 22 127.0.0.1:22. The port 80 mapping serves the web interface and API. The port 22 mapping enables SSH over Tor directly to the service. After restarting Tor, obtain the .onion address from /var/lib/tor/gitea/hostname. Update Gitea's DOMAIN and ROOT_URL in app.ini with this address and restart Gitea. Users will access the web interface at http://your56charsonionaddress.onion and clone repositories with: git clone ssh://git@your56charsonionaddress.onion/user/repo.git. For SSH to work over Tor, clients must configure their SSH to use the Tor SOCKS proxy: add ProxyCommand nc -x 127.0.0.1:9050 %h %p to their SSH config for .onion hosts.

SSH Clone Configuration for Contributors

Contributors cloning via SSH over Tor need to configure their local environment. Add to ~/.ssh/config: Host *.onion with ProxyCommand nc -x 127.0.0.1:9050 %h %p. This routes all SSH connections to .onion addresses through the local Tor SOCKS proxy (port 9050). The torsocks command is an alternative: torsocks git clone ssh://git@youronion.onion/user/repo.git. For Windows contributors, Git Bash with Tor Browser running provides the simplest approach using PuTTY's plink with Tor proxy settings. For CI/CD pipelines needing to push to or pull from the .onion Git, configure the CI agent with Tor client and the same ProxyCommand, ensuring the agent's Ed25519 SSH key is registered in Gitea.

Webhook Delivery and CI/CD Integration

Gitea webhooks fire HTTP POST requests to configured URLs on repository events (push, PR, issue). For fully .onion-integrated CI/CD, configure webhook targets to .onion URLs of CI services (Woodpecker CI, Drone, Gitea Actions). If using a clearnet CI service that needs to receive webhooks from the .onion Gitea, configure a webhook relay: a small clearnet server that receives the webhook and forwards it internally. Alternatively, use polling-based CI rather than webhook-based triggers. For authentication in webhook delivery, Gitea signs payloads with a secret - verify the X-Gitea-Signature header in the receiving endpoint. For internal .onion-to-.onion webhook delivery, Gitea must route outbound HTTP through Tor: set HTTP_PROXY and HTTPS_PROXY environment variables to socks5://127.0.0.1:9050 in the Gitea service environment.

Why Anubiz Host

100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Anubiz Chat AI

Online