Each additional indexer can add network requests, parsed results and cache entries. Jackett's own cache settings cap results per indexer to control RAM, so users who raise cache limits or run many search-heavy applications should leave additional memory headroom.
For large tracker lists and multiple Arr applications issuing frequent queries.Hårdvarukrav för Jackett: CPU, RAM, lagring och indexerarbelastning
Lär dig mer om Jacks krav på maskinvara för indexerare, sökcache, Sonarr-/Radarr-frågor, Docker-distribution och praktisk dimensionering för ZimaOS.
Jackett server requirements at a glance
Jackett is an indexer proxy and translator, not a download client or media transcoder. Upstream documentation does not publish a numerical CPU or RAM minimum; practical demand comes from the number and behavior of indexers, search frequency, the in-memory result cache, optional helper services and the rest of the Arr/download stack sharing the host.
- CPU
- Jackett does not publish a numerical official CPU minimum. Search parsing and tracker requests use CPU, but slow or unavailable trackers can dominate response time without the host being CPU-bound.
- RAM
- Jackett does not publish a numerical official RAM minimum. Its official search-cache documentation explicitly limits cached results per indexer to control RAM usage; the default is 1000 cached results per indexer with a 35-minute TTL.
- Storage
- No fixed official capacity is published. Keep /config persistent for Jackett configuration; /downloads is only needed for torrent blackhole workflows. Jackett does not store the media library itself.
- Network
- Reliable outbound internet, DNS and tracker connectivity are more important than high LAN bandwidth. Jackett proxies searches to tracker sites and returns results to applications such as Sonarr and Radarr.
- GPU
- No dedicated GPU is required for Jackett. Optional FlareSolverr is a separate helper service and should be budgeted separately if your indexers require it.
- Best Zima starting point
- ZimaBoard 2 832 is already a strong Jackett host. Choose the 1664 mainly when Jackett runs beside a larger Arr/download/media stack; choose ZimaCube 2 for integrated storage and whole-server growth rather than for Jackett alone.
From official requirements to the right setup
Jackett sizing starts with indexer behavior and request volume, then adds cache and the other applications that issue those requests.
-
Official requirements
Start with Jackett's role: it translates queries from applications such as Sonarr into tracker-specific HTTP requests, parses tracker responses and returns normalized results. It is not the component that downloads or transcodes media.
-
Confirm your needs
Count active indexers and estimate automated plus interactive search frequency. A larger list can increase concurrent outbound requests, parsing and cache entries, but slow indexers can also make searches feel slow even when local CPU and RAM are adequate.
-
Leave room to grow
Review Jackett's in-memory search cache before adding hardware. The official defaults are a 2100-second TTL and up to 1000 results per indexer specifically to control RAM usage; increasing cache limits trades additional memory for more retained results and fewer repeated tracker requests.
-
Run it on ZimaOS
Install Jackett from the ZimaOS App Store, keep /config persistent, connect the required applications, then monitor CPU, memory, cache behavior and tracker response latency during real searches. If FlareSolverr is required, measure that separate service as part of the total host workload.
Check every playback client
- Number of configured indexers
- Automated RSS/search frequency from Sonarr/Radarr and other apps
- Interactive searches and concurrent requests
- Search cache TTL and max results per indexer
- Slow, blocked or rate-limited tracker behavior
- Whether FlareSolverr is required for Cloudflare-protected indexers
- Persistent /config and optional /downloads blackhole path
- Other Arr apps, download clients and media services sharing the host
Official minimum requirements
Jackett's current official repository documents supported operating systems, installation methods, search-cache behavior and optional FlareSolverr integration, but it does not publish a numerical CPU, RAM or storage minimum. LinuxServer documents the current x86-64/arm64 container and persistent volume layout.
Use the official application behavior to size the host instead of borrowing whole-server specifications from Reddit. The strongest Jackett-specific RAM variable is the in-memory search cache; the strongest latency variables are indexer count, request frequency and slow remote trackers.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Official CPU minimum | No numerical minimum published | The current Jackett README lists supported systems but no core count, CPU family or clock-speed floor. |
| Official RAM minimum | No numerical minimum published | Jackett does not provide a fixed RAM floor. Its search-cache controls are the most explicit upstream guidance about memory use. |
| Search cache | Default TTL 2100 seconds; default maximum 1000 results per indexer | Jackett says the per-indexer maximum exists to control RAM usage and may be increased when many requests are made and sufficient memory is available. |
| Supported container architectures | x86-64 and arm64 in the current LinuxServer image | The container automatically selects the correct architecture-specific image tag. |
| Persistent paths and port | /config; optional /downloads blackhole; WebUI on 9117 | Keep /config persistent across container updates. /downloads is only needed for blackhole torrent workflows. |
| GPU | No dedicated GPU requirement | Jackett performs tracker requests and response parsing, not media transcoding. |
When to upgrade your hardware
Upgrade only after separating local resource pressure from slow trackers and optional helper services. A faster CPU cannot fix an indexer that is offline, rate-limited or slow to respond.
Many indexers and frequent searches increase cache and parsing work
FlareSolverr becomes necessary for protected indexers
Jackett is one component of a larger automation and media host
Jackett integrates with FlareSolverr for some Cloudflare-protected indexers, but FlareSolverr is a separate browser-automation service with its own CPU and RAM demand. Add its resource budget to the host rather than attributing that load to Jackett core.
For users whose required indexers cannot be queried without FlareSolverr.Sonarr, Radarr, download clients, Plex/Jellyfin, databases and backups often consume far more resources than Jackett. Upgrade the host when those services overlap and create sustained contention.
For all-in-one ZimaOS media automation servers.Plan hardware growth with confidence
Jackett scales best by tuning search behavior and separating tracker latency from host limits before adding hardware.
Keep /config persistent
LinuxServer maps /config for Jackett state. Preserve it so indexer definitions, API settings and application configuration survive image replacement or upgrades.
Reliable eMMC/SSD/NVMe is sufficient for Jackett application data; media capacity is determined by the download/media services, not Jackett.Tune the in-memory search cache deliberately
The official default cache keeps results for 35 minutes and caps each indexer at 1000 cached results to control RAM. Raising the maximum can use more memory; reducing TTL or disabling cache can reduce retained cache data but increases repeated tracker requests.
Add RAM only after cache settings and real request volume show a memory constraint.Diagnose slow indexers before upgrading CPU
Jackett issue reports show that a slow or unavailable tracker can make aggregate searches appear slow or unresponsive. Local hardware cannot remove remote tracker latency.
Use reliable DNS/internet, test indexers individually and remove or disable persistently slow sources before buying stronger hardware.Budget optional helper services separately
FlareSolverr and the Arr/download/media applications around Jackett are separate processes. Their combined CPU and RAM can justify a larger host even when Jackett itself remains modest.
Move from ZimaBoard 2 832 to 1664 for more container headroom; use ZimaCube 2 when the broader storage/media stack needs more drives, CPU or networking.Can it run on ZimaOS?
Jackett is available in the ZimaOS App Store and is well suited to a persistent container deployment alongside Sonarr/Radarr and download clients.
Install Jackett from the ZimaOS App Store
Deploy Jackett, open the WebUI and add only the indexers you actually use before connecting Sonarr, Radarr or other clients.
Open Jackett in the ZimaOS App StorePersist configuration and map blackhole downloads only if needed
The LinuxServer container uses /config for persistent state and exposes /downloads for blackhole workflows. Keep application state persistent across updates.
Read the LinuxServer Jackett guideUse Docker and monitor indexer/cache behavior
Jackett upstream recommends Docker especially when avoiding Mono-related platform issues. After deployment, monitor cache settings, remote tracker latency and any FlareSolverr requirement before changing hardware.
Read the Jackett installation documentationChoose Zima hardware for your Jackett and Arr workload
Jackett itself is an indexer proxy with no published numerical CPU/RAM minimum. Choose the host from indexer count, cache settings, FlareSolverr use and—more importantly—the Sonarr/Radarr/download/media services sharing ZimaOS.
Is Jackett running mostly alone, or as part of a larger Arr/download/media stack?
Jackett plus a few light automation services
Start compact. Jackett's core workload does not justify high-end hardware; add memory only when more containers or larger cache settings create real pressure.
- Typical Jackett + light Arr useZimaBoard 2 832
- More containers or memory/cache headroomZimaBoard 2 1664
Full multi-drive media automation server
Choose ZimaCube 2 because the broader download/media/storage stack needs integrated drive capacity, stronger compute or 10GbE—not because Jackett alone does.
- Growing multi-drive media and automation stackZimaCube 2 Standard
- Heavier multitasking or real 10GbE workflowZimaCube 2 Pro
These are workload recommendations, not guaranteed indexer counts or query rates. Remote tracker latency, rate limiting, Cloudflare challenges, cache settings and the surrounding application stack can dominate observed performance.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Jackett itself and a light always-on self-hosted stack. | indexer proxying, cached search results and Arr queries with modest additional ZimaOS services. |
|
Do not interpret this as a benchmark ceiling. Upgrade when the broader server stack, not Jackett alone, creates a measured CPU, memory, storage or networking bottleneck. | Get Now |
| ZimaBoard 2 1664 | Jackett beside more containers, automation services or a larger media stack. | indexer proxying, cached search results and Arr queries while Sonarr/Radarr, download clients, dashboards or other always-on services share the host. |
|
Choose the 1664 for aggregate memory headroom, not because the application has a 16 GB requirement. | Get Now |
| ZimaCube 2 Standard | A growing Arr/download/media server where integrated multi-drive storage is the main reason to choose a larger platform. | Jackett as one service inside a growing multi-drive home-media or automation server. |
|
Choose this platform for integrated storage and broader server capacity; Jackett alone normally does not justify a six-bay NAS. | Get Now |
| ZimaCube 2 Pro | A heavier media automation server that needs more CPU/RAM or 10GbE for the overall stack. | Jackett inside a heavier multi-service ZimaOS host with larger storage, more concurrent applications or 10GbE needs. |
|
10GbE and the stronger CPU are usually justified by storage transfers, media workloads or other services rather than Jackett itself. | 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 distinguish Jackett core requirements from tracker latency and the resources used by the rest of the media-automation stack.
How much RAM does Jackett need?
Jackett does not publish a numerical official RAM minimum. Its official cache settings are the clearest memory guidance: the default cache keeps up to 1000 results per indexer for 35 minutes specifically to control RAM usage.
Does Jackett need a powerful CPU?
There is no published numerical CPU minimum. CPU is used for requests and parsing, but slow or unavailable tracker sites often cause more visible delay than local processor speed.
Does Jackett need a GPU?
No. Jackett does not transcode media. A dedicated GPU is unnecessary for the core indexer-proxy workload.
Can ZimaBoard 2 832 run Jackett?
Yes. Its Intel N150, 8 GB RAM and dual 2.5GbE provide substantial headroom relative to Jackett's lack of any published numeric minimum. The more important question is what Sonarr/Radarr/download/media services share the same host.
How does Jackett search cache affect RAM?
Jackett keeps search results in memory. The official defaults are a 2100-second TTL and a maximum of 1000 results per indexer; increasing the maximum can consume more memory, while lowering TTL or disabling cache reduces retained cache data but can cause more tracker requests.
Does adding more indexers always require a faster server?
No. More indexers can increase requests, parsing and cached results, but overall search time may be dominated by one or more slow remote trackers. Test tracker latency before assuming the host is CPU-bound.
Does FlareSolverr change Jackett hardware requirements?
It can change whole-host requirements because FlareSolverr is a separate service used for some Cloudflare-protected indexers. Size its CPU and memory separately and add that to the ZimaOS host budget.
When should I choose ZimaCube 2 instead of ZimaBoard 2 for Jackett?
Choose ZimaCube 2 when the wider media automation stack needs integrated multi-drive storage, more concurrent services or 10GbE. Jackett by itself normally does not justify a six-bay NAS.
What sources and further reading informed this Jackett hardware guide?
Jackett upstream documentation is the authority for supported systems, Docker guidance, search cache and FlareSolverr integration. LinuxServer documents the active x86-64/arm64 container, /config, /downloads and port 9117. The provided Reddit thread describes a mixed Plex/Arr/Jackett/Blue Iris/VM host, so its i9/32 GB figures were deliberately excluded as Jackett requirements.
