Gitea with Actions on an Offshore VPS

For teams that already use GitHub Actions extensively, the workflow syntax is a strong reason to stick with that ecosystem. Gitea Actions implements a compatible runner protocol that accepts the same `uses:` action references, the same `run:` shell steps, and the same matrix builds. Existing `.github/workflows/` files often work without modification (just rename them to `.gitea/workflows/` and update any GitHub-specific URLs). The whole stack - git, Actions, container registry (Gitea includes a built-in OCI registry), package registry (npm, Maven, PyPI, NuGet, etc), issue tracker, pull requests, wiki - runs in a single Go binary plus a small database (SQLite for tiny instances, Postgres or MySQL for anything serious). On a 2 vCPU / 4 GB RAM VPS, Gitea hosts thousands of repos and runs CI for a 10 to 20 person team comfortably. Self-hosting means you own the repos. There is no risk of GitHub flagging your repo for terms-of-service violations and locking access. You define the storage, the retention, the audit log. For projects that touch sanctions, scraping, adult content, or any area where a GitHub TOS review might end badly, Gitea on an offshore VPS is the safer home.

Gitea itself is tiny - 100 to 300 MB RAM at idle, single-binary deployment. The database (Postgres recommended for production) adds a few hundred MB. The disk is dominated by git repository content. A team with 200 small to medium repos typically uses 20 to 50 GB. Large monorepos or many forks of upstream projects push that into hundreds of GB. Actions changes the sizing math. The runner is a separate Go binary that registers with the Gitea server and pulls jobs. Each job runs in a Docker container (or directly on the host for shell-style runners). Plan on 1 to 2 GB RAM per concurrent runner slot, plus enough headroom for the container images you build. For most small teams, a 4 GB RAM VPS hosts Gitea plus 2 concurrent runner slots comfortably. Storage growth from Actions has two sources - downloaded action repositories cached on the runner (small, capped by retention) and build artifacts uploaded to Gitea's storage backend (configurable). Set short artifact retention (7 to 14 days) unless you have a specific reason to keep them longer. The Gitea container registry is the other growth driver - prune old image tags regularly.

Install Gitea via the official binary. Create a system user: `useradd -r -m -d /var/lib/gitea -s /bin/bash gitea`. Create directories: `mkdir -p /var/lib/gitea/{custom,data,log} && mkdir -p /etc/gitea && chown -R gitea:gitea /var/lib/gitea && chown gitea:gitea /etc/gitea`. Download the binary: `wget -O /usr/local/bin/gitea https://dl.gitea.com/gitea/1.21.5/gitea-1.21.5-linux-amd64 && chmod +x /usr/local/bin/gitea`. Write a systemd unit at `/etc/systemd/system/gitea.service` that runs Gitea as the gitea user with the right WorkingDirectory and ExecStart `/usr/local/bin/gitea web --config /etc/gitea/app.ini`. Start: `systemctl daemon-reload && systemctl enable --now gitea`. Visit `http://YOUR_VPS_IP:3000` and complete the web-based install wizard, choosing Postgres as the database for production. Enable Actions in `/etc/gitea/app.ini`: add a `[actions]` section with `ENABLED=true` and `DEFAULT_ACTIONS_URL=https://gitea.com`. Restart Gitea. Install the act_runner binary - the Gitea Actions runner: `wget -O /usr/local/bin/act_runner https://gitea.com/gitea/act_runner/releases/download/v0.2.6/act_runner-0.2.6-linux-amd64 && chmod +x /usr/local/bin/act_runner`. Register the runner with `act_runner register --no-interactive --instance https://gitea.yourdomain.tld --token RUNNER_REGISTRATION_TOKEN --name vps-runner --labels ubuntu-latest:docker://node:18-bullseye`. Run as a systemd service. Push a workflow and verify it runs.