Syncthing keeps metadata/index state for synchronized files. A 2025 Reddit example with about 1.5 million files and 1.5 TB reported that 4 GB RAM became restrictive and that 16 GB was much smoother. Treat this as large-file-count field evidence, not a universal requirement.
For photo archives, source trees, mail stores and other libraries containing huge numbers of small files.Syncthing Hardware Requirements: RAM, CPU, Storage & Network
Learn Syncthing hardware requirements for RAM, CPU, SSD storage, network speed, file count, hashing and ZimaOS hardware choices.
Syncthing hardware requirements at a glance
Syncthing does not publish one universal minimum CPU, RAM or disk specification. Small sync jobs can run on very modest devices, while millions of files, first-time hashing, many folders/devices and high-speed transfers can use substantially more memory, CPU and storage I/O.
- CPU
- There is no universal official CPU minimum. Syncthing hashes new/changed files with SHA-256 and encrypts all transferred data, so initial scans, large changes and fast links benefit from a faster CPU. Once everything is in sync, official documentation says CPU use should normally be negligible.
- RAM
- There is no current official RAM minimum. A 2018 Syncthing community answer cited typical telemetry of roughly 18–195 MiB at that time, but modern large-file-count deployments can use far more. File count, folders, devices, concurrency and scanning activity matter more than total terabytes alone.
- Storage
- Syncthing's index database is separate from the synced payload and should be kept on fast, reliable local storage. Current official tuning guidance specifically recommends putting the index database on SSD for high performance.
- Network
- Network path directly affects sync speed. Current official troubleshooting guidance says to check for relayed connections first, then low-powered CPUs and network performance. A faster NIC only helps when both endpoints, disks and the actual network path can sustain it.
- GPU
- Syncthing does not need a GPU. Hashing, encryption, compression, database/index work and filesystem I/O are CPU/storage/network tasks.
- Best Zima starting point
- ZimaBoard 2 832 is already a strong Syncthing home-server starting point with an Intel N150, 8 GB RAM and dual 2.5GbE. Use SSD for the index/database. Choose 1664 for very large file counts or more co-hosted apps; move to ZimaCube 2 when multi-drive storage capacity is the larger requirement.
From official requirements to the right setup
Syncthing sizing starts with file count and change rate, then checks hashing/encryption load, index-database storage, direct versus relayed connectivity and the number of folders/devices.
-
Official requirements
Estimate file count as well as total bytes. A few large media files can be easier on metadata/index memory than millions of small files even when total capacity is similar.
-
Confirm your needs
Plan for first scans, rescans and changed-file hashing. Syncthing uses SHA-256 for new/changed files and encrypts network traffic, so a faster CPU and fast local storage matter most during active synchronization rather than idle periods.
-
Leave room to grow
Keep the Syncthing index database on reliable local SSD. Current upstream tuning guidance explicitly recommends a 64-bit build and SSD-backed index database for high-performance setups.
-
Run it on ZimaOS
Test a representative initial sync and large update while monitoring resident RAM, CPU, SSD latency and network path. Confirm that peers connect directly rather than through a relay before blaming the server hardware for low throughput.
Check every playback client
- Total file count, not only total terabytes
- Number of synchronized folders and remote devices
- Initial scan/re-hash frequency and change rate
- 64-bit Syncthing build
- Local SSD placement for the index database
- Direct peer connection versus relay
- LAN/WAN speed and wired versus wireless network
- Other ZimaOS backup, media and container workloads
Official minimum requirements
Current Syncthing documentation does not publish a single minimum CPU, RAM or storage table. It instead explains that performance varies with file hashing, encryption, compression, database/index work, filesystem scans, storage latency and network connectivity.
Do not promote the old 18–195 MiB telemetry range or a Raspberry Pi RAM size into an official minimum. For ZimaOS, use a modern 64-bit host, place the index database on SSD, and scale RAM/CPU from file count, active changes, devices and throughput.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU minimum | No universal official minimum published | Hashing, compression and encryption cost CPU time. Official FAQ guidance says low-powered devices can become the sync-speed bottleneck. |
| RAM minimum | No universal current official minimum published | Memory demand varies with folders, devices, file count, index size, concurrency and active synchronization. |
| Architecture | 64-bit build recommended for high performance | Current official tuning guidance explicitly starts high-performance recommendations with a 64-bit build. |
| Index database | SSD recommended | Current official tuning guidance explicitly recommends placing the index database on SSD. |
| CPU-intensive operations | SHA-256 hashing, encryption, optional compression and scanning | Current official FAQ explains that these operations create the major CPU load, especially during first syncs and large changes. |
| Connection path | Direct connection preferred | Current official troubleshooting says to check whether a connection is relayed when sync speed is unexpectedly low. |
When to upgrade your hardware
Upgrade Syncthing hardware when file-count scale, hashing load, memory pressure or storage/network throughput is measured as the bottleneck.
Millions of files push memory beyond the current host
Initial scans and large changes keep the CPU saturated
Index or small-file I/O becomes storage-bound
New or changed files must be hashed, while transferred data is encrypted and may be compressed. If CPU remains saturated and storage/network still have headroom, a faster processor can reduce synchronization time.
For frequent large changes, high-speed LAN sync and repeated rescans.Syncthing's official tuning guidance recommends SSD for the index database, and community users report large gains from SSD when syncing many small files. Move index/app data to SSD before assuming more RAM will solve the bottleneck.
For very large folder trees, many small files and high-change-rate libraries.Plan hardware growth with confidence
Syncthing scales best when index storage, synchronized payload storage and network topology are planned separately.
Keep the index database on SSD
This is a direct current upstream performance recommendation. The database contains file metadata and is accessed during scanning, reconciliation and synchronization.
Use SATA or NVMe SSD for Syncthing app/index data on ZimaBoard 2 or ZimaCube 2.Use large HDDs for bulk synchronized data when appropriate
Large media and archive files are often sequential enough for HDDs, while the small index database still benefits from SSD. This separates capacity economics from metadata IOPS.
Keep the index on SSD and place large synchronized payloads on SATA HDDs when capacity is the priority.Reduce concurrency when RAM or disk I/O is limited
Current Syncthing tuning options let users control concurrent folders, incoming requests, copiers, hashers and writes. More concurrency can improve speed only when CPU, memory and storage can support it.
Tune concurrency before replacing a server that is only overloaded by aggressive parallel settings.Fix relay/network limits before buying faster hardware
Current official FAQ guidance says a relay can be the reason for slow synchronization. Direct connectivity, network quality and the slower endpoint can cap throughput regardless of the central node's specifications.
Use wired 2.5GbE where useful, but validate direct connections and the complete path before upgrading NICs.Can it run on ZimaOS?
Syncthing is currently available in the ZimaOS App Store under Productivity. ZimaOS provides an always-on x86 home-server deployment path with direct access to local SATA/SSD/HDD storage.
Install Syncthing from the ZimaOS App Store
ZimaOS currently lists Syncthing as an open decentralized file-synchronization app, suitable for keeping files synchronized across personal devices without a traditional cloud-storage intermediary.
Open Syncthing in the ZimaOS App StorePut Syncthing index data on local SSD
Map the application/index database to fast persistent storage. Current Syncthing upstream tuning specifically recommends SSD for the index database in high-performance configurations.
Read Syncthing tuning guidanceKeep synchronized folders on storage sized for the data
The payload can live on larger attached SSD/HDD volumes while the index remains on faster local SSD. This allows storage capacity to grow independently from the Syncthing application container.
Read Syncthing configuration guidanceChoose Zima hardware for your Syncthing workload
Syncthing is light enough for ZimaBoard 2 832 in normal home use, but very large file counts can turn memory and SSD I/O into meaningful constraints. ZimaCube 2 becomes attractive mainly when the synchronized repository itself needs many drives and much more capacity.
Is this a normal personal synchronization node or a very large multi-drive repository with huge file counts?
Normal personal/home sync with moderate file count
Start with ZimaBoard 2 832 and use SSD-backed Syncthing index data. Its Intel N150, 8 GB RAM and dual 2.5GbE provide ample headroom for ordinary household synchronization. Choose 1664 when file count or co-hosted services grow substantially.
- Personal/home Syncthing with SSD-backed indexZimaBoard 2 832
- Large file count or more co-hosted appsZimaBoard 2 1664
Large central repository with many drives, devices or millions of files
Choose ZimaCube 2 for the broader storage requirement. Standard suits a capacity-first repository with moderate memory demand; Pro adds 16 GB RAM, stronger CPU and 10GbE for higher file-count, hashing and multi-service headroom. Creator Pack adds no Syncthing-specific GPU benefit.
- Multi-drive storage-first synchronization repositoryZimaCube 2 Standard
- Large file-count repository and heavier multitaskingZimaCube 2 Pro
- Only when unrelated GPU/AI workloads also require itZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed file-count or synchronization-throughput benchmark. Performance depends on Syncthing version, file count, change rate, hashing, devices, concurrency settings, relay/direct path, filesystem, storage latency and network speed.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | The best-value current Zima option for normal household Syncthing and a compact always-on synchronization node. | Personal documents, photos, device sync, moderate file counts and several lightweight ZimaOS services. |
|
The 32 GB eMMC should not be treated as a large synchronization repository. Millions of files or many other containers can also make 8 GB less comfortable even when total data volume is moderate. | Get Now |
| ZimaBoard 2 1664 | A compact Syncthing node with more memory for very large file indexes and additional home-server services. | Large folder trees, more devices, heavier synchronization activity and broader Docker/home-server use. |
|
Do not claim 16 GB is required for Syncthing. Most normal home workloads fit comfortably below this; the extra RAM is valuable when file counts or co-hosted services become large. | Get Now |
| ZimaCube 2 Standard | A storage-first central Syncthing repository with a large multi-drive dataset. | Multi-terabyte synchronized folders, family device repositories, backups of synced data and moderate self-hosted services. |
|
Standard has 8 GB RAM, so a ZimaBoard 2 1664 can offer more memory headroom for huge file counts if multi-drive capacity is not required. | Get Now |
| ZimaCube 2 Pro | A large central synchronization/NAS server with many files, frequent changes, multiple services and high-speed networking. | Millions of files, multi-drive repositories, high-change-rate folders, backups, databases and other ZimaOS services. |
|
10GbE does not guarantee 10 Gbps Syncthing throughput. Hashing, encryption, slow peers, disks, Wi-Fi/WAN links or relay connectivity can all become the lower ceiling. | Get Now |
| ZimaCube 2 Creator Pack | A Syncthing-backed storage server already purchased for separate AI, GPU or creator workloads. | Large synchronized storage plus unrelated local AI, creator and GPU applications. |
|
Extreme overkill for Syncthing alone. Never recommend Creator Pack merely for a larger synchronized library or faster file transfers; storage/file-count requirements are better addressed by drives, SSD index storage, RAM and network design. | 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
These answers separate older Syncthing community memory observations from current official tuning guidance and modern large-file-count user experience.
How much RAM does Syncthing need?
Syncthing does not publish one current universal RAM minimum. Memory varies with file count, folders, devices, indexing and active synchronization. The 2018 forum figure of 18–195 MiB was a snapshot of typical telemetry at that time, not a modern minimum or maximum.
Is 2 GB RAM enough for Syncthing?
It can be enough for a modest file count and simple dedicated node. The 2026 Ubuntu community discussion considered a Raspberry Pi 4 2GB for Syncthing plus Tailscale, but the thread's 4-GB remarks were about Ubuntu/Raspberry Pi support rather than a Syncthing-specific minimum. File count and storage quality remain more important.
Why can Syncthing use much more RAM with millions of files?
Syncthing maintains metadata/index state for synchronized files, and filesystem watching/scanning also consumes resources. In the supplied 2025 Reddit thread, a user with about 1.5 million files and 1.5 TB reported poor behavior with 4 GB RAM and much smoother operation after moving to 16 GB. This is real-world evidence, not a universal 16-GB requirement.
Does Syncthing need a powerful CPU?
Not while idle, but CPU matters during synchronization. Current official documentation says new/changed files are SHA-256 hashed and transferred data is encrypted, with optional compression. Large scans and fast links can therefore make a low-power endpoint the bottleneck.
Should the Syncthing index database be on SSD?
Yes for a performance-oriented setup. Current official configuration-tuning guidance explicitly says to use a 64-bit build and place the index database on SSD. Large synchronized payloads may still live on HDDs when capacity is more important.
Does Syncthing need a GPU?
No. Syncthing's expensive operations are hashing, encryption/compression, database/index work, filesystem scanning and data transfer. A dedicated GPU provides no normal Syncthing hardware advantage.
Why is Syncthing slow even on a fast server?
Check the connection path first. Current official FAQ guidance says to verify that the devices are not connected through a relay, then check whether a low-powered endpoint or the network itself is the bottleneck. Faster central hardware cannot compensate for a slow peer or path.
Can ZimaBoard 2 run Syncthing?
Yes. ZimaOS currently provides a Syncthing App Store package, and ZimaBoard 2 832 has an Intel N150, 8 GB RAM and dual 2.5GbE, which is a strong home-sync starting point. Add SSD-backed index storage and size SATA/SSD/HDD capacity from the files you actually synchronize.
What sources and further reading informed this Syncthing hardware guide?
The supplied 2018 Syncthing Community Forum answer from project maintainer Jakob Borg said resource needs depend on workload and cited then-current telemetry showing memory usage commonly around 18–195 MiB; this historical range is not promoted into a current minimum. The supplied 2025 Reddit thread shows both extremes of practical use: one user reports a Raspberry Pi Zero W working well as a small central node, while another reports that roughly 1.5 million files/1.5 TB were too slow with 4 GB RAM and became much smoother after upgrading to 16 GB; another commenter highlights the benefit of SSDs for many small files. The supplied May 2026 Ubuntu Community discussion considers Raspberry Pi and small x86 systems for a combined Syncthing repository/Tailscale node, but its 4-GB discussion is primarily about Ubuntu's Raspberry Pi support rather than an official Syncthing memory requirement. Current Syncthing upstream tuning and FAQ documentation were used separately as the authority for SSD index placement, 64-bit high-performance configuration, hashing/encryption CPU load and relay troubleshooting.
