Self-Hosted Git on a No-KYC VPS: Forgejo, Gitea and CI Runner Sizing

If you want your own Git server instead of a GitHub account tied to your identity, the short answer is that the Git part is cheap and the CI part is not. Forgejo or Gitea — the lightweight, self-hosted Git forges most people pick — will run comfortably on a 1 GB VPS. The moment you add continuous integration runners that build Docker images or install npm packages, you need several times more CPU, RAM and disk. Sizing a self-hosted Git server on a no-KYC VPS is mostly about deciding whether CI lives on the same machine.

The direct answer: how much server you actually need

A small Forgejo or Gitea instance with a handful of users and a few dozen repositories typically sits around 150–300 MB of resident memory with SQLite as the database. It's a single Go binary, so there's no PHP-FPM pool or JVM heap to tune. That means:

• Git hosting only, 1–5 users: the €4.99/mo Iron 1 plan (1 vCPU, 1 GB RAM, 20 GB SSD) is enough to run the forge itself. The practical ceiling is disk, not RAM.
• Git plus one CI runner, small team: Iron 2 at €9.99/mo (2 vCPU, 4 GB RAM, 45 GB SSD) is the realistic starting point. One concurrent build job wants a core and a gigabyte or two to itself.
• Several concurrent jobs, a container registry, or a monorepo: Iron 3 at €19.99/mo (4 vCPU, 8 GB, 75 GB) upward. Docker image layers and build caches eat disk faster than any other workload on this list.
• GitLab CE instead of a lightweight forge: GitLab's own documentation puts the floor at 4 GB of RAM plus swap, and that floor is genuinely a floor — Gitaly, Puma, Sidekiq, Redis and PostgreSQL all run as separate processes. Plan for Iron 3 minimum, Iron 4 (8 vCPU, 16 GB) if you want CI on the same box.

If you're still mapping workloads to tiers generally, the broader no-KYC VPS plan sizing guide covers the same arithmetic across other use cases.

Where the disk actually goes

RAM gets all the attention, but disk is what kills small self-hosted Git servers. Budget for four separate things:

Bare repositories. Git is efficient; source code is small. A few hundred text-heavy repos rarely pass a couple of gigabytes. Binary assets are a different story — a repo with committed images, compiled artefacts or design files can be 10× the size of its working tree because every historical version is stored.

Git LFS. If you enable large file storage, it's stored outside the pack files and grows without the benefit of delta compression. On a 20 GB plan, LFS is how you run out of space in a month.

The container registry. Forgejo and Gitea both ship a built-in OCI registry. Each image build pushes new layers, and nothing deletes the old ones unless you configure garbage collection. Five Node.js images at 400 MB each, rebuilt daily for a month, is well past 20 GB.

CI workspaces and caches. Docker build cache, node_modules, Go module caches, pip wheels. A single pipeline can write several gigabytes per run and only reclaim it if you prune.

The practical rule: Git hosting alone fits in 20 GB. Git plus CI with containers wants 45 GB as a starting point, and you should still prune images on a schedule.

Should CI run on the same VPS?

Running the forge and the runner on one server is simpler and cheaper, and for occasional builds it's fine. There are two good reasons to split them onto a second VPS.

The first is availability. A runaway build that fills the disk or pins both cores will also take down the web UI and git push. On a single-vCPU plan, one compile job makes the forge feel broken.

The second is blast radius. CI runners execute code from your repositories, often including code from dependencies you don't audit. A runner with Docker socket access is effectively root on the host. Keeping that away from the machine holding every repository, issue and access token is a meaningful separation — the same reasoning behind splitting workloads across two cheap servers rather than stacking everything on one.

Two Iron 1 instances cost less than €10/mo combined, and a runner-only box can be rebuilt from scratch whenever you want without touching your repositories.

What self-hosting your Git actually hides — and what it doesn't

This is the part worth being precise about, because it's usually the reason people leave a hosted forge in the first place.

What moving off GitHub or GitLab.com genuinely removes: your repository list, private repo contents, issue and pull request history, CI logs, and the account identity attached to all of it. No platform account tied to an email address, no phone verification, no terms-of-service relationship with a company that can disable your account. Commit activity graphs and the timing patterns they reveal stay on your own disk.

What it does not hide:

• Commit author metadata. Your name and email are baked into every commit object. If you've been pushing with a real email, migrating the repo carries that email with it. Set user.email deliberately before your first commit on a new identity.
• The hostname. If you serve the forge over HTTPS with a publicly trusted certificate, the hostname appears in Certificate Transparency logs permanently. Pick the domain and registrar accordingly — see the notes on anonymous domain registration and CT log exposure.
• Your connection. Every git push comes from your IP to the server's IP. Self-hosting changes who holds the logs, not whether the connection exists.
• The disk itself. A VPS host can read the underlying virtual disk. No-KYC signup removes identity from the account, not visibility of the data — the honest breakdown of what a VPS provider can see applies here exactly as it does to any other workload.

That last point matters for threat modelling: self-hosted Git on any provider protects you from platform policy decisions and account linkage far better than it protects raw source code from a determined host or a lawful order.

Why signup friction matters for this specific workload

Developer tooling is where identity trails accumulate quietly. A hosted forge wants an email and often a phone number. A CI service wants a linked account. A registry wants a login. Each one is another record connecting your code to you.

A VPS account that needs no email, name, phone or ID removes that layer at the infrastructure level: IronBalkans issues a random account ID and a recovery key, takes payment in Monero, Bitcoin or Litecoin at live market rate, and deploys a full-root KVM instance in Bucharest in under 60 seconds. Every plan includes a dedicated IPv4 and DDoS protection, which matters more than usual for a service you expose SSH and HTTPS on. You can have a Forgejo instance reachable and your first repo pushed inside an afternoon, with no verification queue in between.

Common mistakes

No backups of the database. People assume Git's distributed nature means their clones are the backup. Clones contain commits — not issues, pull requests, labels, wiki pages, user accounts or webhook configuration. Dump the database and back it up off-site; encrypted restic or Borg backups with tested restores are the right shape for this.

Leaving registry garbage collection off. Disk fills, Git operations start failing with confusing errors, and the cause isn't obvious. Schedule pruning from day one.

Exposing SSH on port 22 with password authentication so git@ works. Git over SSH should use keys only, with the forge's built-in authorized_keys handling. Password auth on a public Git port invites constant brute force.

Buying for today's repo size. Teams that add Docker-based CI three months in routinely outgrow a 20 GB plan. If CI is on the roadmap, start at Iron 2.

Skipping email entirely and then wondering why nothing notifies. Forgejo needs an SMTP relay for password resets and notifications. Self-hosting outbound mail on a fresh VPS IP is its own project.

FAQ

Forgejo or Gitea? Forgejo is a community-governed fork of Gitea with largely compatible resource requirements and migration paths. Either works; the sizing in this article applies to both.

Can I run CI on a 1 GB VPS? For simple test suites and static site builds, sometimes. For anything involving Docker builds, webpack, or compiling, you'll hit memory limits or swap thrashing quickly.

How much bandwidth does CI use? More than the Git traffic. Base image pulls and package downloads on every run add up, though 4 TB on Iron 2 covers a small team's pipelines with large margin.

Can I mirror to GitHub as a backup? Yes, push mirroring works — but understand it re-links your repository to a platform account and publishes your commit metadata there.

Get started

Decide first whether CI lives on the same machine; that single choice determines your plan. Git hosting alone runs happily on the smallest tier, while anything with container builds belongs on Iron 2 or above. When you're ready, compare the tiers on the IronBalkans pricing page or create an account — no email, no ID, crypto only, running in under a minute.