Git Repository Hosting on Tor Hidden Service

Gitea is a lightweight self-hosted Git service written in Go. Download the Gitea binary for Linux amd64 from the official releases page (do this from a clearnet machine and transfer via Tor, or download directly on the server via torsocks wget). Create a git system user, a dedicated directory for Gitea files, and a MariaDB database for Gitea. Run Gitea with the GITEA_WORK_DIR environment variable set. During the first-run wizard (accessible at http://localhost:3000 initially), configure the database, SSH server settings, and critically: set Base URL to http://youronion.onion:3000 (or port 80 if proxied via nginx). After installation, Gitea serves the web interface on localhost:3000. The Tor hidden service maps port 80 (or 3000) to this address. SSH access for git clone operations requires separate Tor hidden service configuration: map port 22 to localhost:22 where the standard SSH daemon or Gitea's built-in SSH server listens. Disable HTTP clone if you want SSH-only access to reduce attack surface.

Git clone, push, and pull via SSH over Tor requires client-side SSH configuration. On the developer's machine, configure ~/.ssh/config: Host youronion.onion ProxyCommand nc -x 127.0.0.1:9050 %h %p. This routes SSH connections to the .onion address through the local Tor SOCKS5 proxy using netcat (nc). After this configuration, git clone git@youronion.onion:user/repo.git works transparently. For Windows developers: use GitBash with torsocks (available via WSL) or configure Git's core.sshCommand to use a SOCKS5-aware SSH. For HTTP(S) git operations via Tor: configure git's http.proxy setting: git config --global http.proxy socks5h://127.0.0.1:9050. This routes all git HTTP operations through Tor. For HTTPS: Gitea on .onion with self-signed certificate requires git config --global http.sslVerify false (or add the self-signed cert to git's SSL store). SSH is preferred over HTTP for .onion Gitea access because it uses Tor's transport without additional proxy configuration once the SSH config is set.

Gitea's default configuration includes several features that make external HTTP requests: avatar loading from Gravatar, package registry features with external index access, and update checks against the Gitea release API. Disable all external connections in app.ini: set OFFLINE_MODE = true in the [server] section (this disables Gravatar and uses local avatars), set DISABLE_WEBHOOKS = false but configure webhooks only to .onion endpoints, disable the Gitea federation features if not needed. User registration: configure DISABLE_REGISTRATION = false initially to create accounts, then set to true to prevent unauthorized access. For a team development server, use organization-level permissions. Repository visibility: configure private-by-default for new repositories. Gitea's built-in issue tracker, wiki, and project boards all operate locally without external dependencies. The release and attachment download feature can serve binary builds to team members via the .onion address - useful for distributing compiled software versions.

Continuous integration for a .onion Gitea server requires CI runners that connect via Tor. Gitea Actions (compatible with GitHub Actions syntax) can run runners on the same server or external machines connected via Tor. Gitea Act Runner (the official Gitea Actions runner) connects to the Gitea server via webhook - configure the runner to connect to Gitea's .onion address via SOCKS5. For Docker-based runners: configure Docker daemon to use Tor SOCKS5 proxy for downloading images. For builds that need external dependencies (npm packages, Go modules, apt packages): route package manager traffic through Tor in the CI configuration. Alternative CI tools: Jenkins with the Gitea plugin, or Drone CI - both can be configured to connect to .onion webhooks. A full .onion CI/CD pipeline (Gitea + runner on same or adjacent servers) enables complete software development workflow within the Tor network: code editing, review, CI testing, and artifact distribution all without clearnet exposure.

Gitea stores data in two places: the database (repository metadata, issues, users) and the filesystem (actual git repositories in GITEA_WORK_DIR/repositories/). Backup both components. Database backup: mysqldump gitea_database | gzip > gitea-db-backup.sql.gz. Repository backup: tar -czf gitea-repos-backup.tar.gz /opt/gitea/repositories/. For high availability: configure Gitea with a shared database (MariaDB Galera cluster or replicated PostgreSQL) and shared repository storage (NFS or object storage like Minio). In a Tor-isolated setup: run two Gitea instances, each with their own .onion address, with repository mirroring between them via Gitea's built-in mirror feature (configured to clone from the peer's .onion address via Tor). This provides redundancy without clearnet exposure. For developer experience: maintain the primary Gitea .onion address as stable, and use the secondary as a private backup (not shared with users). Mirror repositories are automatically synced by Gitea's background job queue.