Large Git histories, Git LFS objects, releases and package registries can dwarf the Gitea application footprint. Storage capacity, IOPS and backup windows become the practical upgrade trigger.
For media-heavy repositories, binaries, container/package registries and long project histories.متطلبات أجهزة Gitea: ذاكرة الوصول العشوائي ووحدة المعالجة المركزية والتخزين والمستودعات
تعرّف على متطلبات أجهزة Gitea من حيث ذاكرة RAM ووحدة المعالجة المركزية والتخزين وSQLite وPostgreSQL وGit LFS وActions وأجهزة ZimaOS.
Gitea hardware requirements at a glance
Gitea is explicitly designed to be lightweight. Current official Gitea 1.27 documentation says a Raspberry Pi 3 is powerful enough for small workloads and that 2 CPU cores with 1 GB RAM is typically sufficient for small teams/projects.
- CPU
- Current official guidance says 2 CPU cores are typically sufficient for small teams/projects. This is a practical small-workload sizing point, not a universal hard minimum for every repository, package registry or CI workload.
- RAM
- Current official guidance pairs the small-team 2-core baseline with 1 GB RAM. The current ZimaOS Gitea page displays 256 MB minimum memory, but that package-level number should not replace the current upstream small-team guidance.
- Storage
- Repository data, Git LFS objects, packages, Actions artifacts and backups dominate storage. The application itself is lightweight; size SSD/HDD capacity from repositories and retention rather than a small binary footprint.
- Database
- Current official Gitea supports built-in SQLite plus PostgreSQL 12+, MySQL 8.0+, MariaDB 10.4+ and MSSQL 2012 SP4+. SQLite keeps a personal/small server simple; external PostgreSQL/MySQL becomes more useful as concurrency and reliability needs grow.
- CI/CD
- Gitea Actions support does not mean the Gitea web server should be sized for build jobs. Act Runner can run separately, and CI workload CPU/RAM/storage should be budgeted for the runner rather than added to the Gitea Server baseline.
- Best Zima starting point
- ZimaBoard 2 832 is far above Gitea's current 2-core/1-GB small-team guidance and is an excellent personal/small-team Git server. Choose 1664 for larger databases and co-hosted services; ZimaCube 2 is mainly justified by large repositories, LFS/package storage and broader NAS workloads.
From official requirements to the right setup
Gitea sizing starts with the official small-workload baseline, then adds repository size, users/concurrency, database choice, Git LFS/packages, Actions runners and the other ZimaOS services sharing the host.
-
Official requirements
Start with current official guidance: Raspberry Pi 3 is sufficient for small workloads, and 2 CPU cores plus 1 GB RAM is typically sufficient for small teams/projects.
-
Confirm your needs
Separate Gitea Server from repository storage. Source code may be small, while Git LFS objects, release files, package registries and artifacts can turn storage capacity and backup time into the dominant requirement.
-
Leave room to grow
Choose the database deliberately. SQLite is built in and keeps personal/small deployments simple; PostgreSQL/MySQL/MariaDB are appropriate when the database and concurrency requirements justify an external service.
-
Run it on ZimaOS
Keep Actions runners separate in the capacity model. Build/test jobs can consume far more CPU/RAM than Gitea itself, so monitor the Gitea server and runner resources independently before upgrading hardware.
Check every playback client
- Number of active developers and concurrent Git/web operations
- Repository count and total Git history size
- Git LFS, release assets and package registry volume
- SQLite versus PostgreSQL/MySQL/MariaDB
- Gitea Actions and whether runners are local or separate
- SSD storage for active repositories and database
- Backup/snapshot retention and restore requirements
- Other ZimaOS developer and home-server services
Official minimum requirements
Current Gitea 1.27 documentation does not present a single hard universal minimum. Instead, it gives practical lightweight reference points: Raspberry Pi 3 for small workloads and 2 CPU cores + 1 GB RAM as typically sufficient for small teams/projects.
Use 2 cores + 1 GB RAM as the current official small-team sizing reference, not as a guaranteed limit. Repository/LFS/package growth, database load and CI runners can require much more storage or compute than the Gitea web service itself.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Small-workload device | Raspberry Pi 3 | Current official docs say it is powerful enough to run Gitea for small workloads. |
| Small-team CPU | 2 CPU cores typically sufficient | Current official system-requirements guidance for small teams/projects. |
| Small-team RAM | 1 GB RAM typically sufficient | Paired with the 2-core small-team guidance; not a hard universal maximum/minimum. |
| Git | Git 2.0.0 or later | Current official requirement; Git LFS is available when enabled and Git is 2.1.2+. |
| Database | SQLite built in; PostgreSQL 12+, MySQL 8.0+, MariaDB 10.4+, MSSQL 2012 SP4+ | Current official database preparation guidance. |
| ZimaOS package memory | 256 MB displayed minimum memory | Current ZimaOS App Store value; keep it separate from upstream's 1-GB small-team sizing guidance. |
When to upgrade your hardware
Gitea upgrades are driven mainly by repository/storage growth, more concurrent developers and CI/package workloads rather than the lightweight Go web service alone.
Repositories, LFS and packages outgrow the active SSD
More developers and database traffic increase concurrency
Actions runners consume build-grade compute
More pushes, clones, pull requests, issue activity and API use increase CPU/database work. Move from a tiny SQLite setup to more RAM and an external database when measured concurrency justifies it.
For growing teams and shared development environments.CI builds/tests can need many cores and gigabytes of RAM even when Gitea Server stays light. Treat runner compute as a separate workload and isolate it when necessary.
For projects using frequent Gitea Actions builds, tests, containers or compilation.Plan hardware growth with confidence
Gitea scales best when the Git service, database, repository storage and Actions runners are separate layers in the hardware plan.
Keep active repositories and database on SSD
Git operations and database queries benefit from responsive local storage, while repository/LFS volume determines how much capacity is needed.
Use SATA/NVMe SSD for Gitea AppData and active repositories.Move larger deployments to PostgreSQL/MySQL
SQLite is convenient for small servers. External database services give more flexibility as concurrency, reliability and backup requirements grow.
Reserve additional RAM and SSD capacity for PostgreSQL/MySQL when needed.Separate Actions runners
Keep build/test compute away from the Gitea web/database process so a heavy job does not make Git hosting unresponsive.
Run Act Runner separately or dedicate CPU/RAM limits based on build workload.Move bulk LFS/package/archive data to larger storage
Large binaries and package artifacts are a capacity problem, not evidence that Gitea Server itself needs a bigger CPU.
Use ZimaCube 2 multi-drive storage when repositories and artifacts become NAS-scale.Can it run on ZimaOS?
Gitea is currently available in the ZimaOS App Store under Developer. The current listing shows 256 MB minimum memory and a v1.26.2 update line, while upstream 1.27 documentation gives 2 cores/1 GB as the typical small-team sizing reference.
Install Gitea from the ZimaOS App Store
The current ZimaOS listing provides Gitea as a self-hosted software-development service with Git hosting, collaboration, package registry and CI/CD features.
Open Gitea in the ZimaOS App StoreDo not confuse the 256 MB package value with small-team sizing
ZimaOS currently displays Minimum memory 256 MB, while current upstream Gitea documentation says 1 GB RAM with 2 CPU cores is typically sufficient for small teams/projects. Use upstream guidance for planning.
Read current Gitea requirementsSize repository data and runners separately
A ZimaOS Gitea server can remain lightweight while LFS, package artifacts and CI builds consume substantial storage or compute. Put those resource layers in the overall server plan.
Read Gitea installation documentationChoose Zima hardware for your Gitea workload
ZimaBoard 2 832 is already far above Gitea's current small-team CPU/RAM reference. Larger Zima systems are selected for repository/LFS/package capacity, database growth, CI runners and broader developer/NAS workloads.
Is Gitea serving personal/small-team repositories, or becoming a large code/package/CI storage platform?
Personal or small-team Git hosting
Start with ZimaBoard 2 832. Four N150 cores and 8 GB RAM greatly exceed the current 2-core/1-GB small-team reference. Choose 1664 only when a larger database, runners or other containers need more RAM.
- Personal/small-team GiteaZimaBoard 2 832
- More services, larger DB or local runner loadZimaBoard 2 1664
Large repositories, packages, LFS or broader developer NAS
Choose ZimaCube 2 when storage becomes the reason to scale. Pro is appropriate for a heavier all-in-one development/home-lab stack; Creator Pack only when unrelated GPU/AI workloads justify it.
- Storage-first code/LFS/package archiveZimaCube 2 Standard
- Heavier developer/NAS and CI stackZimaCube 2 Pro
- Only when separate GPU/AI workloads require itZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed developer/repository count. Git history, LFS/packages, Actions jobs, database choice and clone/push concurrency can change requirements substantially.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Personal and small-team Gitea with ordinary repositories. | Gitea, SQLite/PostgreSQL, repositories, issue tracking and several lightweight developer services. |
|
Use added SSD as repositories, packages, LFS and backups grow; onboard eMMC is the likely first constraint. | Get Now |
| ZimaBoard 2 1664 | Gitea with more co-hosted developer services, external database or local runners. | Larger repository set, PostgreSQL, package registry, automation and additional containers. |
|
Do not claim Gitea requires 16 GB. | Get Now |
| ZimaCube 2 Standard | Storage-first Gitea with large repositories, LFS objects, packages and backups. | Large code/archive storage plus moderate development and NAS services. |
|
Choose it for capacity, not because Gitea needs an i3-class server. | Get Now |
| ZimaCube 2 Pro | A heavier all-in-one developer/NAS host with Gitea, databases, runners and many services. | Large repositories/packages, PostgreSQL, CI runners, backups and broader homelab workloads. |
|
Separate runner resource requirements before attributing CI load to Gitea. | Get Now |
| ZimaCube 2 Creator Pack | Gitea on hardware independently required for GPU/AI development workloads. | Gitea plus local AI, GPU build/test or creator applications. |
|
Extreme overkill for ordinary Git hosting; recommend only for independent GPU workloads. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
The supplied Gitea sources use several different practical tiers. Current official Gitea documentation is used as the authority when those numbers disagree.
How much RAM does Gitea need?
Current official Gitea 1.27 documentation says 1 GB RAM with 2 CPU cores is typically sufficient for small teams/projects. Treat that as a small-workload planning reference, not a hard universal minimum.
Can Gitea run on Raspberry Pi?
Yes. Current official documentation explicitly says a Raspberry Pi 3 is powerful enough for small Gitea workloads.
Is 512 MB RAM the current Gitea minimum?
The supplied Mintlify mirror lists 1 core/512 MB as a minimum and 2+ cores/2+ GB as recommended. Current official Gitea 1.27 documentation instead gives Raspberry Pi 3 as a small-workload reference and says 2 cores/1 GB is typically sufficient for small teams. Use the current official site for planning.
Why does ZimaOS show 256 MB minimum memory?
That is the current ZimaOS App Store package-level value. It demonstrates that the package is lightweight but should not override the upstream 1-GB small-team sizing reference.
What does Contabo recommend?
Contabo's 2026 Gitea Docker guide cites the current official small-team guidance of 2 CPU cores and 1 GB RAM. Its VPS deployment includes PostgreSQL/reverse-proxy infrastructure, so size the combined stack rather than Gitea alone.
What does CubePath recommend?
CubePath recommends 2 CPU cores, 2 GB RAM and 20 GB+ disk for its Gitea server deployment. This is a comfortable third-party deployment tier, not the upstream minimum.
Are HOSTKEY's 1-GHz CPU, 1-GB RAM and 1-GB disk numbers official?
No. Those are HOSTKEY's hosting requirements. The 1-GB RAM figure happens to align with current upstream small-team guidance, but its CPU/disk numbers remain provider guidance.
Can ZimaBoard 2 832 run Gitea?
Yes. Four N150 cores and 8 GB RAM provide substantial headroom over Gitea's current small-team guidance. Add SSD storage based on repositories, LFS/packages and backups.
What sources and further reading informed this Gitea hardware guide?
Contabo's 2026 self-hosting guide correctly cites the current official 2-core/1-GB small-team guidance and then builds a fuller Docker/PostgreSQL VPS stack around it. The supplied CubePath URL was not directly fetchable with its challenge-token URL during this audit, but CubePath's indexed current Gitea guidance recommends 2 cores, 2 GB RAM and 20 GB+ disk as a third-party deployment tier. The supplied Mintlify Gitea mirror lists 1 core/512 MB minimum and 2+ cores/2+ GB recommended; because this differs from the current official 1.27 wording, it remains secondary. HOSTKEY lists 1-GHz CPU, 1 GB RAM and 1 GB free disk as provider guidance. Current official Gitea documentation was separately checked and used as the authority for Raspberry Pi 3 support, 2 cores/1 GB small-team sizing, Git 2.0+ and supported databases.
