copyparty verifies upload checksums, so high-speed transfers can expose CPU and storage limits even when the network link is faster.
2.5GbE/10GbE file-sharing users.متطلبات أجهزة CopyParty: ذاكرة الوصول العشوائي، ووحدة المعالجة المركزية، والتخزين، ومشاركة الملفات
تعرّف على متطلبات CopyParty/copyarty من حيث وحدة المعالجة المركزية وذاكرة الوصول العشوائي والتخزين والصور المصغّرة والرفع والشبكة، ثم اختر أجهزة ZimaOS المناسبة.
CopyParty requirements at a glance
ZimaOS lists the app as CopyParty; the upstream project name is copyparty. Upstream does not publish a numerical CPU or RAM minimum because its basic file-server mode is very lightweight. Resource use rises when you enable high-speed uploads, hashing, file indexing, thumbnails, media probing or FFmpeg-powered media features.
- CPU
- No numerical official minimum. Basic browsing/downloads are light; upload checksum verification, indexing and thumbnail/media processing add CPU work.
- RAM
- No numerical official minimum. Normal file serving is light, but image/video thumbnail generation can create large transient memory spikes for difficult media.
- Runtime
- Current upstream development documentation requires Python 3.9+ when running/building from source; official Docker images are also available.
- Storage
- The main capacity requirement is the files you serve. Index/history/thumbnail cache storage is much smaller but should be persistent when those features are enabled.
- Network
- File-transfer throughput scales with NIC, storage speed and checksum CPU. Multi-gigabit uploads can expose HDD or CPU limits before the web UI itself is constrained.
- Best Zima starting point
- ZimaBoard 2 832 is already ample for normal CopyParty file sharing. ZimaCube becomes useful when CopyParty fronts a large multi-drive file library.
From official requirements to the right setup
CopyParty sizing starts with the file-transfer and media features you actually enable.
-
Official requirements
Start with plain upload/download and authentication. The upstream project is a portable single-file-oriented server, so the base application is not a heavy workload.
-
Confirm your needs
Add indexing, hashing and media features deliberately. Upload integrity checks consume CPU, while thumbnails and FFmpeg-powered processing can add CPU and RAM bursts.
-
Leave room to grow
Match storage and NIC speed to the target transfer rate. A fast 2.5/10GbE network can be limited by one HDD, filesystem layout or checksum processing even when CopyParty itself is responsive.
-
Run it on ZimaOS
Install CopyParty from ZimaOS, test a representative large upload plus thumbnail/index workload, then identify whether CPU, RAM, disk or network is the actual bottleneck.
Check every playback client
- Concurrent uploads/downloads
- Target 1/2.5/10GbE throughput
- Checksum/hash verification
- File indexing/search
- Image/video thumbnail generation
- FFmpeg media features
- Storage filesystem and disk speed
- Authentication and exposed protocols
Official minimum requirements
copyparty does not publish a universal CPU/RAM minimum.
Do not turn a tiny Python process into a blanket 'low-memory' promise. Media thumbnail generation and high-throughput checksum work can be much heavier than simple file serving.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU | No numerical minimum published | Checksum, indexing and media processing determine heavier CPU demand. |
| RAM | No numerical minimum published | Thumbnail generation can cause workload-specific memory spikes. |
| Python | Python 3.9+ in current development docs | Relevant when running/building from source. |
| Primary web port | 3923 by default | Current upstream examples commonly expose the main web service on 3923. |
| Optional media tools | FFmpeg / FFprobe recommended | Used for audio/media probing and thumbnails beyond basic image support. |
| GPU | Not required | CopyParty does not document a dedicated-GPU requirement. |
When to upgrade your hardware
Upgrade when transfer, indexing or media-processing features prove the current host is limiting.
Multi-gigabit uploads become CPU or disk limited
Media thumbnails create large RAM spikes
The shared library outgrows compact attached storage
Upstream issue reports show pathological animated-image thumbnails can consume several gigabytes during decoding. This is an edge case but demonstrates that thumbnail workload, not base server RAM, can dominate.
Large photo/video collections with thumbnail generation enabled.File capacity, snapshots/backups and multi-user uploads can become the dominant reason to move to a multi-drive NAS platform.
Large household/team file libraries.Plan hardware growth with confidence
Scale CopyParty by separating lightweight serving from optional indexing/media work.
Disable unnecessary thumbnails/media features
If CopyParty is mainly an upload/download endpoint, turning off expensive thumbnail/media processing can reduce CPU/RAM pressure.
Useful on low-power always-on hosts.Use SSD for indexes/cache when the file tree is large
Search/index/history/cache operations benefit from responsive local storage even when bulk files live on HDDs.
Keep bulk data on capacity drives and app/index data on SSD when needed.Match NIC speed to storage throughput
A 10GbE port does not guarantee 10Gbps file transfer when the underlying disk pool or checksum CPU cannot keep up.
Upgrade the slowest path rather than only the server CPU.Use a multi-drive ZimaCube for large shared libraries
CopyParty itself stays light while the storage requirement can grow dramatically.
Choose ZimaCube when file capacity and disk layout drive the server purchase.Can it run on ZimaOS?
ZimaOS currently lists the upstream copyparty project as CopyParty under Productivity.
Install CopyParty from the ZimaOS App Store
Use the packaged private file-sharing server for browser uploads, downloads and supported file protocols.
Open CopyParty in the ZimaOS App StoreUse upstream copyparty for feature behavior
The upstream project documents indexing, protocol, thumbnail and performance options under the lowercase copyparty name.
Read copyparty upstream documentationTreat media tooling as optional load
Upstream development notes identify FFmpeg/FFprobe as recommended media tools and warn that some image conversion paths can be RAM-heavy.
Read copyparty development notesChoose Zima hardware for CopyParty
CopyParty itself is lightweight; storage capacity, transfer speed and optional media processing determine the useful Zima tier.
Is CopyParty serving a normal file share or a large multi-drive/high-throughput library?
Normal home file sharing
ZimaBoard 2 832 provides ample compute and dual 2.5GbE.
- Normal CopyParty serverZimaBoard 2 832
- More indexing/media/servicesZimaBoard 2 1664
Large multi-drive file library
Use ZimaCube when capacity and disk layout—not the web app—drive the requirement.
- Multi-drive file-sharing serverZimaCube 2 Standard
- 10GbE / heavier file-service stackZimaCube 2 Pro
No fixed transfer-rate, file-count or concurrent-user guarantee is implied. Filesystem, storage media, hashing, thumbnails, protocol, NIC and client performance all matter.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A normal private CopyParty file server. | File uploads/downloads, authentication and light indexing. |
|
Large thumbnail/media jobs or storage throughput can become the bottleneck before the base server. | Get Now |
| ZimaBoard 2 1664 | CopyParty plus more services and heavier indexing/media features. | More file-server features and shared-container headroom. |
|
The NIC remains 2.5GbE per port and bulk storage must still keep pace. | Get Now |
| ZimaCube 2 Standard | A large multi-drive CopyParty file library. | File sharing, backups and high-capacity household/team storage. |
|
Choose this for storage capacity, not because CopyParty needs a Core i3. | Get Now |
| ZimaCube 2 Pro | A higher-throughput CopyParty/storage platform. | Large library, more services and a 10GbE-capable server path. |
|
10GbE still depends on disk-pool and checksum performance. | 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
FAQ topics follow query fan-out around the CopyParty/copyparty naming difference, RAM, thumbnails, 2.5/10GbE transfers, WebDAV and large file libraries. Community discussion is used for workload discovery, while upstream docs define behavior.
Is CopyParty the same project as copyparty?
Yes. ZimaOS displays the app as CopyParty, while the upstream project and repository use the lowercase name copyparty.
How much RAM does CopyParty need?
Upstream does not publish a RAM minimum. Basic file serving is light, but thumbnail/media processing can create workload-specific memory spikes.
Why can thumbnail generation use a lot of RAM?
Decoding animated or high-resolution media can require far more memory than the compressed file size suggests; upstream has documented extreme animated-AVIF cases.
Can CopyParty saturate 2.5GbE?
Potentially, but the result depends on disk speed, checksum verification, filesystem and client. The app itself is not the only limit.
Does CopyParty need SSD storage?
Not for ordinary file serving. SSD becomes useful for app/index/cache data or as working storage when a large file tree or high transfer rate makes HDD latency visible.
Does CopyParty need FFmpeg?
Not for basic file sharing. FFmpeg/FFprobe are recommended upstream for richer audio/media probing and thumbnail/transcoding features.
Can ZimaBoard 2 832 run CopyParty?
Yes. Its Intel N150, 8 GB RAM and dual 2.5GbE are well above the needs of normal file serving.
When is ZimaCube 2 useful for CopyParty?
When the shared file library needs multiple drive bays, more integrated storage or a 10GbE-class server path. CopyParty alone does not require NAS-class compute.
What sources and further reading informed this CopyParty hardware guide?
The upstream copyparty repository and development notes define the file server, Python/media tooling and performance behavior. Upstream issues document edge-case thumbnail memory pressure. ZimaOS confirms the CopyParty listing, while Reddit was used for current file-server query fan-out.
