Gitea VPS requirements: RAM, CPU, disk, and what really sizes the server

Sizing guide

Our recommendations, derived from the sourced figures below. Not measurements.

Official requirements

What people report in practice

Individual reports, not controlled tests. Versions, hardware and settings differ, so treat these as data points, not guarantees.

• Gitea idled at 79 MB of RAM and 373 MB of total Docker disk, 30 seconds after the documented install on a clean 2 vCPU / 8 GB VM (one reading). Forgejo, in the same sweep, read 100 MB and 383 MB. The authors note the OS with Docker already used about 600 MB on their boxes, on top of the app

  Independent test of 96 self-hosted apps, Google Cloud e2-standard-2, Ubuntu 26.04, 28 Sep 2026. Idle with no users or data

  Blog SelfHost Atlas: Self-hosted app RAM usage, 96 apps measured (2026) · checked Nov 1, 2026

• docker stats on a running instance: gitea 148.2 MiB and 0.15% CPU, PostgreSQL 45.3 MiB, an idle runner 32.1 MiB. The guide's own table puts the stack at about 230 MB idle, about 400 MB with 5–10 active users and about 600 MB during a CI build, and says 1 GB is the minimum, 2 GB with a CI runner

  Tutorial by a VPS provider (Virtua Cloud) on its own 4 vCPU / 8 GB plan, Gitea 1.25.5 with PostgreSQL 17, 2026

  Blog Virtua Cloud: Self-host Gitea on a VPS with Docker Compose · checked Nov 1, 2026

• "My instance of Gitea uses about 120MB of RAM, Postgres 10-20MB", on a 1 GB / 1 CPU VPS also running Nginx, Nextcloud, a mail server, Synapse and more, with the advice to add at least 1 GB of swap. Others: 512 MB under Cloudron for 3 users pushing a few times a week, and a 1 GB Linode shared with SVN, websites and package repos "with no problems"

  r/Gitea thread, Sep 2022, answering how big a VPS very light personal use needs

  Reddit r/Gitea: For very light personal usage, how big a VPS does Gitea need? · checked Nov 1, 2026

• Peak RAM during YunoHost's automated package test was 372 MB for Gitea (333 MB still in use after the test), against 231 MB for Forgejo. A maintainer added that production use may differ

  YunoHost forum, Jan 2025, quoting the packaging CI jobs. A short install test, not a production instance

  Forum YunoHost forum: RAM usage for Gitea and Forgejo · checked Nov 1, 2026

• A public Gitea on Kubernetes kept getting OOM-killed after memory reached about 7 GiB. The cause was crawlers from large cloud and social-media networks fetching pages for AI training, not a leak; a maintainer said each request costs memory and big repositories cost more. Blocking those networks' ASNs at the ingress brought memory back to normal, and Redis for cache and sessions helped further

  GitHub issue, Feb to May 2025, Gitea 1.23.x

  GitHub GitHub go-gitea/gitea #33520: OOM caused by numerous crawls · checked Nov 1, 2026

• A public instance maxed its CPU and used about 12 GB of RAM. A maintainer traced the diagnosis file to the Git compare/diff page, and the logs showed crawler traffic from big cloud networks comparing old tags with the newest. After turning on the option to block expensive pages for anonymous users, the reporter wrote: "Not facing high CPU & RAM load anymore"

  GitHub issue, Jun to Jul 2025, Gitea 1.24.2 in Docker

  GitHub GitHub go-gitea/gitea #34916: Gitea consumes excessive CPU and RAM when mirror tokens expire · checked Nov 1, 2026

• docker stats showed a quiet Gitea growing from about 130 MB to 240 MB in 11 hours and later to 5 GB, while htop on the host showed the gitea binary at about 250 MB. A maintainer found no leak in Gitea's own heap and pointed at how container memory is counted

  GitHub issue, Dec 2023, Gitea 1.21 nightly in Docker with PostgreSQL

  GitHub GitHub go-gitea/gitea #28606: Slow progressive memory leak with Docker container · checked Nov 1, 2026

What drives Gitea's RAM use

A small Go server, then whatever each request costs

An idle Gitea sits around 80–150 MiB in published tests (SelfHost Atlas; Virtua Cloud). Memory rises with work: rendering diffs and blame views, comparing tags, big clones and the git processes Gitea starts for them. A maintainer traced one 12 GB spike to the compare page (#34916). A few people using it normally never get near that.

Crawlers turn cheap pages into expensive ones

A forge has a URL for every file at every commit, every blame, every compare and every issue filter. AI crawlers that walk them all pushed one public Gitea to about 7 GiB and repeated out-of-memory kills (#33520). The fix in both reports was to stop the traffic, not to add RAM. A private instance doesn't have this problem.

Disk: repositories, LFS, packages, Actions and the indexer

Everything users push lands on the VPS disk: repositories, LFS objects, the package registry, and Actions logs and artifacts, which are kept 365 and 400 days by default. Code search is off by default because it takes about six times the repository size, and source archives are generated on request and kept until a nightly cleanup (cheat sheet). The install itself is small: 373 MB of Docker disk in one test (SelfHost Atlas).

CI is a separate workload

Gitea only queues Actions jobs. The runner runs them, usually in containers, one at a time unless you raise runner.capacity (runner docs). A build can need far more RAM and CPU than the forge, so size for your heaviest job, not for Gitea.

Gotchas on a VPS

• Keep public instances away from crawlers. By default Gitea is open to search engines and serves no robots.txt (docs), and admins report AI crawlers ignoring robots.txt anyway (#33966). For a forge that's just for you, set REQUIRE_SIGNIN_VIEW = true or reach it over a VPN or tunnel such as Pangolin. For public code, REQUIRE_SIGNIN_VIEW = expensive keeps anonymous visitors off the costly code pages, and [qos] ENABLED = true sheds logged-out traffic first under load (cheat sheet).
• Ports 3000 and 222 are public by default. The example compose file publishes 3000:3000 and 222:22 on every interface (docs), and Docker's published ports bypass UFW (Docker docs). Bind the web UI to 127.0.0.1:3000:3000 behind Caddy or Nginx with HTTPS, and finish the install wizard before the site is reachable, since whoever opens it first sets it up.
• Check self-registration. The current cheat sheet lists DISABLE_REGISTRATION as true by default, but the install wizard and older configs can switch it on (cheat sheet). Look in app.ini. With Actions on, a stranger who can create a repository can try to run workflows on your runner, and the docs' rule is never to provide a runner to a repository or instance you don't trust (Actions overview).
• A runner on the same box is close to root. Container jobs need Docker or Podman, and the usual compose setups mount the Docker socket into the runner (example), which lets jobs control the host's Docker. host labels run jobs with no isolation at all (runner docs). Use them only for your own repositories, or put the runner on a separate VPS.
• Version 28 follows 1.27. 28.0.0 is the release after 1.27.3, not a giant jump (blog; forum). Read its two breaking changes first, and update scripts that download binaries, since the file names changed. Pin a tag such as 28.3.0 rather than latest, and take a backup before every minor upgrade: the docs say a downgrade across minor versions needs that backup (upgrade docs).
• docker stats can overstate Gitea's memory. In one report docker stats showed 5 GB while the gitea process on the host used about 250 MB (#28606). Before resizing the server, check Site Administration's system status or a diagnosis report (Monitor, then Trace), and set a container memory limit so one runaway request restarts Gitea instead of freezing the VPS.
• Back up with Gitea stopped, and off the server. gitea dump makes one ZIP of repositories, database and config, and the docs say Gitea "must be shutdown during backup" for a consistent copy (docs). A short nightly stop is fine for a personal forge. Copy the ZIP to another machine.

Cheapest plans that fit

Gitea, private, one person, SQLite, no CI on the box: 1 GB RAM and 1+ vCPU

Threshold: Published idle readings of 79–150 MiB; 1 GB leaves room for the OS, a proxy and big clones. Not yet measured by us (source). Only plans with at least 1 vCPU are listed.

Gitea for a small team (official guidance): 1 GB RAM and 2+ vCPU

Threshold: Official: "2 CPU cores and 1GB RAM is typically sufficient for small teams/projects" (source). Only plans with at least 2 vCPUs are listed.

Gitea plus an Actions runner on the same VPS: 4 GB RAM and 2+ vCPU

Threshold: Our estimate, not a measurement: Gitea's few hundred MiB plus room for typical container builds. Size up for heavy builds (source). Only plans with at least 2 vCPUs are listed.

Prices checked Oct 28, 2026 on each provider's official pricing page. EUR prices converted at the ECB rate of Oct 27, 2026 (1 € = $1.115) only for ranking. See all plans on the cheapest 4 GB VPS page.

Related pages

• Forgejo requirements: Forgejo is a community fork of Gitea with the same light footprint; its page covers release lines and the same crawler problem.
• Coolify requirements: Coolify can deploy apps from a Git source on push; a self-hosted forge plus Coolify replaces GitHub plus a PaaS.
• Uptime Kuma requirements: Run Uptime Kuma on another small VPS to watch your forge's web UI and certificate from outside.
• Pangolin requirements: Keep a private Gitea off the public internet and reach it through a Pangolin tunnel instead.
• n8n requirements: Gitea webhooks can trigger n8n workflows on pushes, issues and pull requests.
• Vaultwarden requirements: Another light single-container app that fits next to a private Gitea on a 1–2 GB VPS.