Remote users add upload demand and can also trigger transcoding when the original bitrate, codec or playback device is not suitable. Several simultaneous remote conversions can become a much heavier workload than local Direct Play.
For households sharing one Emby server with family or friends outside the local network.Hårdvarukrav för Emby Server: CPU, RAM, lagring och omkodning
Lär dig mer om Emby-serverkrav för Direct Play, HD- och 4K-transkodning, fjärrströmning, Emby Premiere samt maskinvarualternativ för ZimaOS.
Emby server requirements at a glance
Start with playback method. Direct Play uses the source file as-is, Direct Stream keeps the video track unchanged while repackaging or converting other tracks, and full video transcoding is the workload that usually determines CPU and graphics demand.
- CPU
- Emby's official no-transcoding minimum is an Intel Core 2 Duo 1.6 GHz or better. Its HD-transcoding baseline is a 2.4 GHz Core 2 Duo or better, but those legacy figures are software baselines rather than modern 4K or multi-user purchasing targets.
- RAM
- Emby's official minimum is 512 MB RAM on Linux and 1 GB on Windows or macOS, with 2 GB listed for HD transcoding. Separately, an Emby Community hardware article suggests 8 GB as a practical starting point for most users and 16 GB or more for larger libraries or multiple transcodes.
- Storage
- Emby publishes no fixed media-capacity requirement. Size storage from the actual library and growth plan; SSD storage for the operating system and Emby metadata can improve responsiveness, while bulk media can live on appropriately sized HDD or SSD storage.
- Network
- Emby's official recommended network configuration includes wired Gigabit Ethernet and at least 10 Mbps upload bandwidth when serving content remotely. Real demand depends on combined stream bitrate, simultaneous users and whether remote playback triggers transcoding.
- Emby Premiere
- Hardware-accelerated transcoding and HDR tone mapping when transcoding are Emby Premiere features. The published free exceptions for hardware acceleration are NVIDIA Shield and WD NAS devices, not a general Linux/ZimaOS exception.
- Best Zima starting point
- Start with ZimaBoard 2 for a Direct Play or Direct Stream-focused personal server with suitable media storage. Choose ZimaCube 2 when you need integrated multi-drive growth, recurring transcoding, more simultaneous users or heavier ZimaOS workloads.
From official requirements to the right setup
Emby sizing starts with whether clients can play the original video without re-encoding, then changes with subtitles, HDR, remote bitrate, simultaneous users, storage growth and other services sharing ZimaOS.
-
Official requirements
Use Emby's official system requirements as a software floor: very light hardware can serve compatible media without transcoding, while full video conversion raises CPU, memory and accelerator demand.
-
Confirm your needs
Test representative files on every important client. Direct Play uses the file as-is. Direct Stream keeps the video track unchanged but can repackage the container or convert audio/subtitles. Full transcoding decodes and re-encodes the video and is much more CPU-intensive.
-
Leave room to grow
If recurring video transcoding or HDR tone mapping is expected, confirm Emby Premiere and then verify the complete acceleration path: supported GPU/iGPU, Linux driver, device exposure to the ZimaOS container, codec support, subtitle behavior and actual hardware use during a test transcode.
-
Run it on ZimaOS
Install Emby from the ZimaOS App Store, map persistent media and application paths, create libraries, then test local and remote playback with the actual codecs, subtitles and client devices you expect to use.
Check every playback client
- Video codec: H.264, HEVC, VP9 or other library formats
- Audio codec and channel format
- Container: MP4, MKV or another supported format
- Subtitle format and whether burn-in is required
- Resolution, bitrate, bit depth and HDR characteristics
- Direct Play, Direct Stream or full video transcoding
- Local or remote playback and simultaneous users
- Client app, browser and playback-device compatibility
Official minimum requirements
Emby's official system-requirements page separates no-transcoding minimums from an HD-transcoding configuration. These values are software baselines and should not be presented as guaranteed modern 4K, HDR or multi-user performance targets.
Use the no-transcoding figures only as Emby's published software floor. For a new ZimaOS media server, client compatibility, expected transcoding, Emby Premiere, metadata storage, remote bandwidth and simultaneous users are more useful sizing variables than the legacy CPU and RAM numbers alone.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU — no transcoding | Intel Core 2 Duo 1.6 GHz or better | This is Emby's published minimum for playback without video transcoding. Direct Play-focused workloads can therefore be computationally light. |
| RAM — no transcoding | 512 MB Linux; 1 GB Windows or macOS | These are published minimum software requirements, not a recommended memory target for a modern ZimaOS server running multiple applications. |
| HD transcoding baseline | Intel Core 2 Duo 2.4 GHz or better and at least 2 GB RAM | Emby says faster CPU resources may be required when transcoding for multiple devices. Hardware acceleration can reduce CPU load, but actual support depends on the GPU, codec and software path. |
| Media and metadata storage | No single official capacity for every library | Emby publishes no fixed capacity for the media library. An Emby Community hardware article recommends SSD storage for the operating system and Emby metadata to improve responsiveness; bulk media capacity remains workload-dependent. |
| Network | Wired Gigabit Ethernet recommended; at least 10 Mbps upload for remote serving | These are Emby's current published network recommendations. Size real capacity from the combined bitrate of simultaneous streams plus other household traffic. |
| Hardware-accelerated transcoding | Supported on compatible Linux hardware; Emby Premiere required except for published device exceptions | Emby supports NVIDIA NVDEC/NVENC, VA-API and Intel Quick Sync on Linux. The Premiere feature matrix lists hardware-accelerated transcoding and HDR tone mapping when transcoding as Premiere features; NVIDIA Shield and WD NAS are the published hardware-acceleration exceptions. |
When to upgrade your hardware
Upgrade for a defined Emby workload change rather than simply because the server stores more files. Recurring transcoding, subtitle burn-in, remote sharing and simultaneous users are the strongest compute triggers.
More remote users need lower-bitrate streams
Subtitles or client limits trigger video transcoding
4K, HDR or several simultaneous transcodes become normal
Unsupported subtitle formats can trigger transcoding. Emby specifically notes that graphical subtitles such as PGS and VobSub are more likely to require burn-in, and hardware acceleration does not eliminate the significant CPU involvement that subtitle burn-in can create.
For mixed playback devices, image-based subtitles or libraries that frequently fall back from Direct Play.High-resolution or HDR conversion increases processing demand. HDR tone mapping when transcoding is an Emby Premiere feature. Do not infer a fixed stream count from a GPU model alone because codec, bit depth, subtitle burn-in, tone mapping and platform support can change the result.
For larger home theaters, remote 4K libraries and multi-user servers.Plan hardware growth with confidence
Plan Emby media capacity, metadata performance, networking and compute as separate resources. This lets the library grow without turning every storage increase into a full server replacement.
Keep Emby metadata on responsive storage
An Emby Community hardware article recommends SSD storage for the operating system and Emby metadata because it can improve web-interface and library responsiveness. This is practical guidance, not a fixed official SSD-capacity requirement.
Use SSD or NVMe for application data and metadata when practical, while bulk movies, TV and music can live on larger HDD-based storage.Protect the media library independently
Size storage for the real media library, redundancy and expected growth. Availability mechanisms such as RAID do not replace a separate backup of irreplaceable media and important Emby application data.
Keep a separate copy of irreplaceable home video and other media that cannot simply be downloaded again.Size local and remote networking from bitrate
Emby's official network recommendation includes wired Gigabit Ethernet and at least 10 Mbps upload for remote serving. Practical sizing should use the combined bitrate of simultaneous streams plus headroom.
Faster LAN is useful for large library imports, backups and multiple high-bitrate local users; remote playback remains constrained by internet upload bandwidth.Leave headroom for other ZimaOS apps
Emby shares CPU, memory, storage I/O and networking with backups, downloaders, home automation, photo apps, containers and virtual machines running on the same server.
Choose additional RAM and CPU headroom for the services that actually operate at the same time instead of sizing for Emby alone.Can it run on ZimaOS?
Emby is available in the ZimaOS App Store. The practical setup is to map persistent media and application storage correctly, create libraries, then verify the actual playback and acceleration paths used by your clients.
Install Emby from the ZimaOS App Store
Install Emby, open the server web interface and complete the initial library and user setup before testing playback.
Open Emby in the ZimaOS App StoreMap media and persistent application storage
Attach or mount the folders containing your media, then make those paths available to the Emby container. Keep application data persistent so metadata and server configuration survive updates.
Read the Emby setup guideVerify hardware acceleration end to end
On Linux, Emby supports NVIDIA NVDEC/NVENC, VA-API and Intel Quick Sync. A capable GPU or iGPU does not prove that acceleration is active in ZimaOS. Confirm Emby Premiere, the Linux driver, device exposure to the container, codec support and real hardware use during a test transcode.
Read Emby Linux hardware acceleration guidanceChoose Zima hardware for your Emby workload
Confirm Direct Play and Direct Stream compatibility, recurring video transcoding, subtitle burn-in, HDR tone mapping, remote users, storage growth and other ZimaOS services first. Then choose the smallest system with enough media capacity and verified acceleration headroom.
Will your important clients Direct Play or Direct Stream most of your media?
Yes — full video transcoding is uncommon
Prioritize media capacity, responsive metadata storage and reliable networking. Emby's compute demand remains modest when video can be delivered without re-encoding.
- Personal Emby server with light additional ZimaOS appsZimaBoard 2 832
- More apps, users or memory headroom in the same compact platformZimaBoard 2 1664
No — recurring video transcoding is expected
Use stronger and verified hardware acceleration, then validate codecs, subtitles, HDR/tone-mapping behavior and simultaneous conversions. A dedicated GPU is justified only when the real workload needs it.
- Growing multi-drive library with regular supported Intel-accelerated transcodingZimaCube 2 Standard
- More simultaneous transcodes, HDR tone mapping and other always-on servicesZimaCube 2 Pro
- Dedicated NVIDIA GPU plus AI, creator or heavy VM workloadsZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed stream-count benchmark. Results depend on codecs, bitrate, subtitles, HDR and tone mapping, client support, Emby settings, Emby Premiere, Linux drivers, container GPU access and the selected hardware configuration.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A compact Emby server focused on Direct Play or Direct Stream with a small number of light ZimaOS services. | Local playback, light remote use after testing and externally attached SATA or network media storage. |
|
Do not advertise a fixed 4K transcode count. Subtitle burn-in, HDR/tone mapping, codecs and the ZimaOS container acceleration path can shift substantial work back to the CPU. | Get Now |
| ZimaBoard 2 1664 | Direct Play-focused Emby plus more ZimaOS apps, users or memory headroom in the same compact form factor. | Emby beside backups, downloaders, automation or other containers when recurring heavy transcoding is not the primary workload. |
|
Choose it for memory and application headroom, not as an automatic transcoding upgrade over the 832. | Get Now |
| ZimaCube 2 Standard | A growing multi-drive Emby library with stronger 12th-gen Intel CPU and integrated-graphics headroom for supported transcoding. | Several Direct Play clients, media management and regular supported video conversion after testing the actual codecs and subtitles. |
|
Hardware capability does not guarantee a fixed number of HD or 4K transcodes, especially when subtitles or HDR processing add CPU work. | Get Now |
| ZimaCube 2 Pro | More Emby users, a large library and additional always-on ZimaOS services with more CPU, RAM and network headroom. | Concurrent media use, supported hardware transcoding, large media imports and other self-hosted services running beside Emby. |
|
Additional CPU, RAM and media-engine headroom is not a promise of a specific number of simultaneous 4K, HDR or subtitle-burn-in transcodes. | Get Now |
| ZimaCube 2 Creator Pack | Emby combined with a genuine dedicated-GPU requirement, local AI, creator applications or heavy virtual machines. | A mixed server where Emby is one part of a larger GPU-accelerated compute and storage environment. |
|
Usually excessive for an Emby-only Direct Play server. Choose it because the dedicated GPU, 64 GB memory, AI, creator or VM workload is itself required. | 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 cover purchasing, transcoding, networking and migration questions that are not fully addressed in the sections above.
How much RAM does an Emby server need?
Emby's official minimum is 512 MB RAM on Linux and 1 GB on Windows or macOS, with 2 GB listed for HD transcoding. Those are software baselines. Separately, an Emby Community hardware article suggests 8 GB as a practical starting point for most users and 16 GB or more for larger libraries or multiple transcodes.
Does Emby need Emby Premiere for hardware transcoding?
Yes for a normal ZimaOS/Linux deployment. Emby's Premiere feature matrix lists hardware-accelerated transcoding and HDR tone mapping when transcoding as Premiere features. Its published free hardware-acceleration exceptions are NVIDIA Shield and WD NAS devices.
Can ZimaBoard 2 run Emby?
Yes. The Intel N150, 8 GB or 16 GB RAM, dual 2.5GbE and SATA expansion are comfortably above Emby's published no-transcoding software floor. Treat ZimaBoard 2 primarily as a compact Direct Play/Direct Stream or light mixed workload server; recurring hardware transcoding still requires Premiere and successful acceleration inside ZimaOS.
Can ZimaBoard 2 run 4K Emby?
It can serve compatible 4K media through Direct Play when the client and network support the source file. That is different from guaranteeing 4K transcoding. Full conversion depends on codec, bitrate, HDR/tone mapping, subtitles, Emby Premiere, Linux driver support and whether the ZimaOS container can use the N150 graphics device.
Does Emby need a dedicated GPU?
No. Direct Play and many ordinary Emby servers do not need a dedicated GPU. Emby supports Intel Quick Sync and VA-API on Linux, so a compatible Intel iGPU can be sufficient for supported hardware transcoding. A dedicated NVIDIA GPU is most justified when the broader server workload also needs it.
How much upload speed do I need for remote Emby?
Emby's system-requirements page lists at least 10 Mbps upload bandwidth when serving content remotely. Treat that as a baseline rather than a per-stream guarantee: actual demand depends on combined remote bitrate, selected quality limits, simultaneous users and other internet traffic.
Can subtitles force Emby to transcode?
Yes. Emby says subtitles can trigger transcoding when the client does not natively support the subtitle format. Text formats such as SRT or VTT are more commonly supported, while graphical PGS and VobSub subtitles are more likely to require burn-in; Emby also warns that burn-in can still involve significant CPU work with hardware acceleration.
When should I choose ZimaCube 2 instead of ZimaBoard 2 for Emby?
Choose ZimaCube 2 when you want integrated multi-drive expansion, a larger media archive, more simultaneous users, recurring transcoding or several other always-on services. Standard is the first multi-drive step; Pro adds CPU, memory, 10GbE and additional media-engine headroom; Creator Pack is for a real dedicated-GPU or heavier compute need.
What sources and further reading informed this Emby hardware guide?
Emby's official System Requirements page is the authority for the published CPU, RAM and network baselines. The Emby Community hardware article provides practical 8 GB/16 GB and SSD guidance but is not the formal minimum-requirements specification. The two Emby Community threads are anecdotal planning examples, not guaranteed performance benchmarks. The XDA watch-party article is useful only as broader multi-user/community-use context and should not be used to size server hardware. Where any community source conflicts with current Emby documentation, the current official Emby documentation takes precedence.
