Dev · no KYC
Host Gitea on an Offshore VPS
Run your own lightweight Git forge on a no-KYC, crypto-paid VPS and keep every repo, issue, and CI pipeline off third-party clouds.
What it is
Gitea is a self-hosted Git service written in Go — a lightweight GitHub/GitLab alternative offering repositories, pull requests, issues, wikis, releases, and Actions (CI/CD). It ships as a single binary or Docker image with a small memory footprint, making it ideal for teams that want full control over their source code.
Why host it offshore
Source code is among the most sensitive data a team holds; hosting it on a no-identity, offshore VPS keeps it outside the reach of the big code-hosting platforms and their data-retention and takedown regimes. Paying in crypto with no KYC means your project's infrastructure isn't tied to a corporate identity, and unmetered bandwidth lets clones, CI runs, and release downloads flow without metering surprises.
The deploy
A working reference setup
Copy this onto a fresh ChainVPS instance. Replace the placeholders, then bring it up.
# docker-compose.yml — Gitea + PostgreSQL on Ubuntu 24.04
# 1) apt install docker.io docker-compose-v2
# 2) put this file in /opt/gitea and run: docker compose up -d
# 3) open http://SERVER_IP:3000 to finish the web installer
services:
server:
image: gitea/gitea:1.22
container_name: gitea
restart: always
environment:
- USER_UID=1000
- USER_GID=1000
- GITEA__database__DB_TYPE=postgres
- GITEA__database__HOST=db:5432
- GITEA__database__NAME=gitea
- GITEA__database__USER=gitea
- GITEA__database__PASSWD=CHANGE_ME_STRONG_DB_PW
# correct clone URLs — set to your domain once DNS is ready:
- GITEA__server__DOMAIN=git.example.com
- GITEA__server__ROOT_URL=https://git.example.com/
- GITEA__server__SSH_PORT=222
- GITEA__service__DISABLE_REGISTRATION=true
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000" # web UI — front with a TLS reverse proxy in production
- "222:22" # git-over-SSH (host 222 -> container 22)
depends_on:
- db
networks:
- gitea
db:
image: postgres:16
container_name: gitea-db
restart: always
environment:
- POSTGRES_USER=gitea
- POSTGRES_PASSWORD=CHANGE_ME_STRONG_DB_PW
- POSTGRES_DB=gitea
volumes:
- ./postgres:/var/lib/postgresql/data
networks:
- gitea
networks:
gitea:
external: false
Firewall
Ports to open
| Port | Protocol | Purpose |
|---|---|---|
| 3000 | TCP | Gitea web UI and HTTP git — keep behind a TLS reverse proxy (Caddy/Nginx) in production |
| 222 | TCP | Git-over-SSH (host port mapped to container 22) for clone/push over SSH keys |
| 443 | TCP | HTTPS via your reverse proxy once a domain and cert are in place |
| 22 | TCP | Host SSH for admin — keep on a separate port from Gitea's 222 and key-only |
Right-sizing
Which plan you need
VPS Nano/Small (1-2 vCPU, 2 GB RAM)
Solo dev or a handful of users, a few dozen repos, no CI. Gitea idles near 150-200 MB RAM.
VPS Pro (2-4 vCPU, 4-8 GB RAM)
Small team, active pull requests, plus one or two Gitea Actions runners for CI. Add a storage volume for large release artifacts.
Dedicated (or Storage VPS for repos)
Many concurrent users, large monorepos, heavy CI concurrency, or LFS-heavy media. Dedicated CPU keeps clone/pack operations snappy; pair with a Storage plan for repo/LFS data.
Best locations: Pick a privacy-tier location — Switzerland (CH) and Iceland (IS) offer the strongest data-protection posture for source code, with Netherlands (NL), Romania (RO), Moldova (MD), and Luxembourg (LU) as solid offshore alternatives. Choose the region closest to your contributors to cut clone/push latency, since git round-trips are latency-sensitive.
Lock it down
Hardening checklist
- Never expose port 3000 raw to the internet — front Gitea with a TLS reverse proxy (Caddy auto-HTTPS or Nginx + certbot) and set GITEA__server__ROOT_URL to the https domain so clone URLs are correct.
- Set DISABLE_REGISTRATION=true (already in the compose) right after creating your admin account so no one can self-register; invite users manually or via the admin panel.
- Keep git-over-SSH on port 222 and the host's own sshd on a different port, both key-only (PasswordAuthentication no); Gitea manages its authorized_keys internally, so don't hand-edit it.
- Enable 2FA for every account and require it for the admin; rotate the DB password out of the environment into a Docker secret or .env file with 600 perms.
- Back up ./gitea (repos, config, LFS) and a pg_dump of the gitea database on a schedule, and pin the image to a version tag (gitea/gitea:1.22) rather than latest so upgrades are deliberate — read release notes before bumping major versions.
Deploy it on
The right ChainVPS product
Questions
Hosting Gitea — FAQ
Can I run CI/CD without a separate service?
Yes. Gitea has built-in Actions (GitHub-Actions-compatible). Enable it, then register a runner container (gitea/act_runner) against your instance. For real CI load, use a Medium plan or larger so builds don't starve the web service.
SQLite, MySQL, or PostgreSQL?
SQLite works for a single light user and needs no DB container. For any team or growth path, use PostgreSQL as shown in the compose — it handles concurrency far better and is trivial to back up with pg_dump.
How do I migrate my repos off GitHub/GitLab?
Gitea's built-in migration tool imports a repo by URL including issues, PRs, releases, and wiki. Add a token for the source platform in the migration form to pull private repos and metadata.
Does this handle large files (Git LFS)?
Yes, LFS is supported natively and stored under /data. If you host large binaries or media, put ./gitea on a Storage VPS volume and budget disk accordingly — LFS objects add up fast.
Will my code stay private on a no-KYC host?
Your repos live entirely on your VPS disk in your chosen offshore jurisdiction; nothing is mirrored to a third party. Keep registration disabled, use HTTPS + SSH keys, enable 2FA, and take encrypted off-box backups for full control.
More to self-host
Other one-click stacks
Spin up Gitea
in the next 60 seconds.
Unmetered bandwidth · DDoS included · 21 cryptocurrencies · no KYC.