FileFlows' current encoder logic falls back to CPU when a supported hardware encoder is unavailable. CPU x265/AV1 workloads can be dramatically heavier.
Large H.264→HEVC/AV1 library conversions.FileFlowsのハードウェア要件：CPU、RAM、GPU、トランスコード
FileFlowsのCPU、RAM、Intel QSV、NVIDIA、作業用SSD、処理ノードの要件を確認し、適したZimaOSハードウェアを選びましょう。
FileFlows requirements at a glance
FileFlows does not publish a universal CPU or RAM minimum. Its architecture separates a central Server from one or more Processing Nodes; the server includes an internal node, but heavy file conversion can be offloaded or distributed. FFmpeg processing, codec, runner count, temp storage and hardware acceleration determine the real hardware requirement.
- CPU
- No numerical official minimum. CPU fallback encoding can be extremely compute-heavy; runner count multiplies simultaneous processing demand.
- RAM
- No numerical official minimum. Memory depends on active flows/runners, media tools and other services; encoding speed is usually more CPU/GPU/storage-bound.
- Processing nodes
- The FileFlows Server includes an internal processing node and can also distribute jobs to external processing nodes.
- Hardware acceleration
- Current FileFlows can automatically test/use NVIDIA, Intel QSV, AMD AMF, VAAPI and Apple VideoToolbox, then fall back to CPU when unavailable.
- Temporary storage
- Official Docker docs recommend placing the Temp Path on a fast drive such as NVMe because flow runners create temporary files there.
- Best Zima starting point
- ZimaBoard 2 832 is suitable for FileFlows control/server work and Intel-QSV-capable workflows when device passthrough works. ZimaCube 2 Pro is a better all-in-one tier for sustained conversion plus storage.
From official requirements to the right setup
FileFlows sizing starts with what the processing nodes will actually encode or transform.
-
Official requirements
Separate Server and Processing Node roles. The web/control server can be modest, while FFmpeg conversion runs on the internal or external node.
-
Confirm your needs
Define codec and acceleration path. CPU x265/AV1 can be far slower than QSV/NVIDIA/AMD/VAAPI hardware encoding; unsupported decode/filter stages may still fall back to CPU.
-
Leave room to grow
Choose runner concurrency and Temp Path. Multiple simultaneous runners multiply CPU/GPU and temp-disk I/O, and official Docker docs recommend fast NVMe temp storage.
-
Run it on ZimaOS
Install FileFlows from ZimaOS, validate actual hardware encoder detection in a representative flow and measure FPS, CPU/GPU and temp-disk throughput before increasing runner count.
Check every playback client
- Server versus Processing Node role
- File type and codec
- CPU fallback versus hardware encoding
- Intel QSV/NVIDIA/AMD/VAAPI availability
- Runner count
- Fast Temp Path
- Source/output storage throughput
- Remote processing nodes
Official minimum requirements
FileFlows currently documents architecture and hardware-acceleration paths but does not publish a universal CPU/RAM minimum.
Do not invent a single RAM/CPU number. A control-only FileFlows server and a node converting 4K AV1/H.265 files are fundamentally different workloads.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU | No numerical minimum published | CPU encoding/fallback requirements depend heavily on codec and runner count. |
| RAM | No numerical minimum published | Active processing flows and concurrent runners determine practical memory. |
| Default port | 19200 | Current FileFlows server default. |
| Temp Path | Fast drive / NVMe recommended | Official Docker guidance for runner temporary files. |
| Hardware encoders | NVIDIA / Intel QSV / AMD / VAAPI / VideoToolbox | Automatic encoder detection/fallback is documented in current video encoding docs. |
| GPU | Optional, workload-dependent | Hardware acceleration is valuable for video processing but not required for FileFlows control-plane use. |
When to upgrade your hardware
Upgrade FileFlows when measured conversion throughput, runner concurrency or storage I/O is limiting.
CPU fallback makes video conversion too slow
Multiple runners saturate the encoder or temp drive
One server must process and store a large media library
Concurrent processing multiplies compute and temporary-file I/O; adding runners without headroom can reduce total efficiency.
Users processing large media libraries continuously.Source reads, temp files, output writes and media-library storage can make SSD/NVMe/HDD layout as important as CPU/GPU.
All-in-one FileFlows media servers.Plan hardware growth with confidence
Scale FileFlows by distributing nodes and using the right accelerator/storage path.
Use Intel QSV when compatible
FileFlows can pass /dev/dri into Docker and automatically use Intel QSV for supported codecs, with CPU fallback when unavailable.
ZimaBoard 2 and ZimaCube Intel platforms can be useful only when ZimaOS/container driver and device passthrough are correctly configured.Use external processing nodes
Official architecture supports offloading and load balancing work across external nodes instead of replacing the central FileFlows server.
Useful when encoding compute should live on a workstation/GPU host.Put Temp Path on NVMe
FileFlows explicitly recommends a fast temp drive because active flows create intermediate files.
Reduces storage bottlenecks during remux/transcode/copy workflows.Add NVIDIA only for workflows that justify it
FileFlows supports NVIDIA encoding, but dedicated GPU hardware should be selected for codec support, runner count and quality/speed goals rather than the FileFlows UI.
Creator-class hardware is conditional, not a baseline recommendation.Can it run on ZimaOS?
FileFlows is currently listed in the ZimaOS App Store under Media/Developer.
Install FileFlows from ZimaOS
Use the packaged workflow server and persist Data plus media/temp mappings.
Open FileFlows in the ZimaOS App StoreUse FileFlows' Server/Node architecture
The current Docker docs distinguish the central Server from optional Processing Nodes and document internal/external processing.
Read FileFlows Docker architectureVerify hardware encoder support per flow
Current Video Encode documentation automatically tests hardware encoders and falls back to CPU, so actual device support must be verified.
Read FileFlows Video Encode hardware logicChoose Zima hardware for FileFlows
FileFlows is one of the few catalog apps where processing hardware can dominate the entire server design. Pick hardware from codec, runner count and storage path.
Will ZimaOS mainly coordinate FileFlows, or perform sustained media conversion locally?
Control/server plus light or QSV-assisted processing
ZimaBoard 2 can host FileFlows and use its Intel platform when QSV passthrough is verified.
- Entry FileFlows/QSV hostZimaBoard 2 832
- More runners/services headroomZimaBoard 2 1664
Large all-in-one conversion/storage server
Use ZimaCube 2 Pro for stronger CPU, 16 GB RAM, integrated multi-drive storage and 10GbE-capable workflows.
- Heavy media-processing/storage serverZimaCube 2 Pro
No FPS, transcode-time or concurrent-runner guarantee is implied. Codec, source resolution, bit depth, filters, encoder, device passthrough, FFmpeg build and storage all matter.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | FileFlows server plus light processing or verified Intel-QSV flows. | Workflow control, remuxing, audio/image work and moderate video jobs. |
|
N150 CPU fallback can be slow for heavy x265/AV1; QSV must be verified in the container. | Get Now |
| ZimaBoard 2 1664 | FileFlows plus more runners/containers and larger workflow state. | More concurrent services and memory headroom. |
|
More RAM does not make CPU-only video encoding proportionally faster. | Get Now |
| ZimaCube 2 Pro | A heavy all-in-one FileFlows conversion and media-storage server. | Stronger CPU, multi-drive media, fast temp storage and 10GbE-capable file movement. |
|
Dedicated GPU workflows may still need separate/Creator hardware; Pro should not be treated as a universal 4K/AV1 guarantee. | 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 RAM, Intel QSV, NVIDIA, CPU fallback, runners, temp NVMe and distributed nodes. FileFlows community reports are used for real passthrough/encoder problems.
How much RAM does FileFlows need?
FileFlows does not publish a fixed RAM minimum. A control server can be modest, while concurrent processing flows add memory according to the tools and runner count.
Does FileFlows need a GPU?
No for the application itself. Video processing can use NVIDIA, Intel QSV, AMD, VAAPI or Apple VideoToolbox, and FileFlows falls back to CPU when no supported hardware encoder is available.
Can FileFlows use Intel Quick Sync?
Yes. The Docker docs explicitly support Intel QSV via the /dev/dri device, but drivers, permissions and container passthrough must be correct.
Why is FileFlows using CPU even though my Intel GPU is visible?
Community reports show that device visibility alone does not guarantee a usable encoder; driver/toolkit, permissions and codec/filter support can cause CPU fallback.
Should FileFlows temp files be on NVMe?
Official Docker guidance recommends a fast drive such as NVMe for Temp Path because processing runners create intermediate files there.
Can I run FileFlows processing on another computer?
Yes. Processing Nodes are a first-class architecture feature and can offload/distribute work away from the central server.
Can ZimaBoard 2 832 run FileFlows?
Yes for the FileFlows server and many light/QSV-assisted flows. Heavy CPU-only HEVC/AV1 conversion should be benchmarked before committing to large libraries.
When is ZimaCube 2 Pro worthwhile for FileFlows?
When FileFlows is part of a large media-processing/storage server and benefits from the stronger CPU, multi-drive layout, 16 GB RAM and 10GbE-capable path.
What sources and further reading informed this FileFlows hardware guide?
FileFlows' official Docker, video-encoder and hardware-encoder docs define Server/Node architecture, NVMe temp guidance, QSV/NVIDIA configuration and CPU fallback. Current FileFlows Reddit threads were used for real hardware-acceleration troubleshooting, while ZimaOS confirms the current app.
