Autobrr's own install guidance says SQLite suits most setups but suggests PostgreSQL when a large release history is expected. Database growth is therefore a clearer scaling trigger than an arbitrary RAM number.
Long-running instances connected to busy trackers or many feeds.Hardwareanforderungen für Autobrr: CPU, RAM, Datenbank und Automatisierungslast
Erfahren Sie mehr über die Anforderungen von Autobrr an CPU, RAM, SQLite/PostgreSQL und Automatisierung und wählen Sie anschließend die passende ZimaOS-Hardware für Torrent- und Usenet-Workflows.
Autobrr requirements at a glance
Autobrr does not publish a numerical CPU or RAM minimum. It is a lightweight Go-based automation service that listens for releases, evaluates filters and sends matched items to download clients or Arr apps. The more useful sizing variables are release volume, number of indexers/IRC feeds, filter complexity, database history and the rest of the ZimaOS stack.
- CPU
- No numerical official minimum is published. Autobrr spends CPU on parsing announces, applying filters, web/API work and database operations rather than media processing.
- RAM
- No numerical official minimum is published. A third-party managed-hosting template advertises 256 MB with 512 MB ideal, but that is provider sizing rather than an Autobrr requirement.
- Database
- SQLite is the default and Autobrr says it suits most setups. The official install guide recommends PostgreSQL when you expect a large release history.
- Storage
- Autobrr stores configuration, logs and its database in persistent application storage. It is not the bulk download-data store unless your workflow explicitly writes torrent/NZB files locally.
- GPU
- No dedicated GPU is required. Autobrr is an automation/control-plane service, not a transcoder or emulator.
- Best Zima starting point
- ZimaBoard 2 832 is already far beyond typical Autobrr-only needs. Choose 1664 or ZimaCube 2 because the same server also runs download clients, Arr apps, databases or larger storage—not because Autobrr itself needs high-end hardware.
From official requirements to the right setup
Autobrr sizing starts with event volume and database growth rather than raw media throughput.
-
Official requirements
Start with the official Docker deployment: Autobrr needs a persistent `/config` path and exposes its web UI on port 7474; no CPU or RAM reservation is specified by Autobrr itself.
-
Confirm your needs
Estimate how many indexers/IRC channels, feeds and filters are active. A quiet personal setup and a high-volume tracker automation instance can see very different event rates even though both use the same application.
-
Leave room to grow
Plan database growth. Autobrr uses SQLite by default for most setups and explicitly suggests PostgreSQL when you expect a large release history. Current SQLite tuning in the project also uses a larger cache and memory mapping to reduce disk reads.
-
Run it on ZimaOS
Install Autobrr from the ZimaOS App Store, connect the actual torrent/Usenet and Arr clients, then observe CPU, memory, database size and activity during peak announce periods before deciding whether the host needs more resources.
Check every playback client
- Number of configured indexers and IRC channels
- Release/announce volume during peak periods
- Number and complexity of active filters
- Size of retained release history
- SQLite versus PostgreSQL database
- Number of connected download and Arr clients
- Log retention and persistent config/database storage
- Other ZimaOS apps sharing CPU and RAM
Official minimum requirements
Autobrr's current official documentation does not publish a numerical CPU, RAM or disk minimum. Docker examples focus on persistent config, networking and database choice.
Do not convert third-party container limits into an Autobrr minimum. The official guidance points instead to event/database scale: SQLite is appropriate for most setups, while PostgreSQL is available for large release histories.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU | No numerical minimum published | The official Docker guide does not set a CPU limit or reservation. |
| RAM | No numerical minimum published | The official Docker guide does not set a memory limit or reservation. |
| Third-party sizing example | 1 vCPU; 256 MB RAM; 512 MB ideal | A managed-container provider advertises these figures. They are useful as external low-end sizing evidence, not an Autobrr official requirement. |
| Default database | SQLite | Autobrr says SQLite suits most setups. |
| Large-history database option | PostgreSQL | Autobrr recommends PostgreSQL if you expect a large release history. |
| Persistent path / port | /config; Web UI 7474 | From the current official Docker example. |
When to upgrade your hardware
Upgrade Autobrr when event/database scale or the surrounding download stack becomes the bottleneck.
Release history becomes large
Many feeds and filters fire at once
Autobrr shares resources with heavy download clients
Rapid IRC announcements and multiple filters create bursts of parsing, matching, actions and database writes. More CPU/memory headroom can help when the automation plane is genuinely busy.
High-volume tracker automation and multi-indexer setups.qBittorrent, Deluge, NZBGet, unpacking, Arr apps and media servers can dominate the same host's memory, storage and network. Upgrade for the combined peak rather than the Autobrr process alone.
All-in-one ZimaOS media automation servers.Plan hardware growth with confidence
Scale Autobrr by keeping its database healthy and separating control-plane work from bulk download storage.
Keep config and database on reliable local storage
Autobrr persists its configuration and database under `/config`. Database latency and reliability matter more than giving the app a large media disk.
Use reliable eMMC/SSD/NVMe or another persistent local path for application data.Move large release histories to PostgreSQL
Autobrr officially supports both SQLite and PostgreSQL and provides a built-in database conversion command.
Use PostgreSQL when history scale or database-management requirements justify a separate database service.Treat SQLite cache behavior as tuning, not a RAM minimum
Current Autobrr SQLite code uses a 64 MB cache target and memory-maps the first 256 MB of the database to reduce reads. Those are implementation/tuning details, not proof that every instance consumes or requires those exact amounts of physical RAM.
Observe real process memory and database size instead of summing cache/mmap values into a fake requirement.Add server hardware for the download ecosystem
Autobrr can control multiple clients on remote servers, so the automation host itself need not contain all download storage or compute.
Choose larger Zima hardware when the same box also hosts the actual torrent/Usenet, Arr, media and storage workloads.Can it run on ZimaOS?
Autobrr is currently available in the ZimaOS App Store and fits the always-on automation role well.
Install Autobrr from the ZimaOS App Store
Use the packaged app, keep its application data persistent and configure access to the actual download/Arr clients.
Open Autobrr in the ZimaOS App StoreKeep `/config` persistent
The official Docker example maps a persistent config directory and exposes the web UI on 7474.
Read Autobrr Docker installationChoose SQLite or PostgreSQL from history scale
Use SQLite for ordinary deployments and consider PostgreSQL when release history becomes large.
Read Autobrr installation guidanceChoose Zima hardware for your Autobrr workload
Autobrr itself is lightweight. Hardware tiering should follow the number of co-hosted download/media services and storage needs rather than an invented Autobrr CPU target.
Is Autobrr a small automation service, or part of a full download/media stack?
Autobrr plus a modest number of lightweight services
The control-plane workload is small relative to current ZimaBoard 2 resources.
- Personal Autobrr automationZimaBoard 2 832
- More filters, clients and co-hosted appsZimaBoard 2 1664
Full media/download stack with substantial local storage
Move up for integrated drives, larger overall application headroom and local data workflows.
- Multi-drive Arr/download serverZimaCube 2 Standard
- Larger stack and 10GbE storage workflowZimaCube 2 Pro
There is no official Autobrr CPU/RAM minimum. Third-party resource figures and implementation cache settings are reference evidence, not guaranteed sizing rules.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A personal Autobrr instance with ordinary filters and a small automation stack. | IRC/indexer monitoring, filtering and actions to local or remote clients. |
|
Autobrr itself is unlikely to exhaust this hardware; heavy download clients or other containers are more likely to define the limit. | Get Now |
| ZimaBoard 2 1664 | Autobrr with a larger group of Arr, indexer and download services. | More filters, history and always-on co-hosted apps. |
|
Extra RAM is for the combined stack; it is not an Autobrr requirement. | Get Now |
| ZimaCube 2 Standard | A multi-drive automation/download server where storage consolidation matters. | Autobrr plus download clients, Arr apps and local media storage. |
|
Choose it for integrated storage and the broader stack, not because Autobrr requires a Core i3. | Get Now |
| ZimaCube 2 Pro | A larger all-in-one media automation server. | Many services, large local transfers and 10GbE-capable storage workflows around Autobrr. |
|
10GbE and stronger compute primarily benefit the surrounding workload. | 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 Autobrr's actual documentation from third-party container sizing.
How much RAM does Autobrr need?
Autobrr does not publish a numerical RAM minimum. A third-party managed container provider advertises 256 MB with 512 MB ideal, but that is provider sizing rather than an official requirement.
How many CPU cores does Autobrr need?
There is no official numerical CPU minimum. A third-party provider uses 1 vCPU, while Autobrr's own Docker example does not set CPU limits.
Should Autobrr use SQLite or PostgreSQL?
Autobrr says SQLite suits most setups. If you expect a large release history, its install documentation recommends PostgreSQL as the scalable alternative.
Can ZimaBoard 2 832 run Autobrr?
Yes. Its 8 GB RAM and modern Intel N150 provide far more host resources than a typical Autobrr-only workload needs.
Does Autobrr need a GPU?
No. Autobrr parses release announcements, evaluates filters and sends actions to other applications.
Does a 256 MB SQLite mmap mean Autobrr needs 256 MB RAM?
No. The current code memory-maps part of the SQLite database and configures cache behavior for I/O efficiency. Memory mapping is not equivalent to permanently consuming the entire mapped size as physical RAM.
When should I use ZimaCube 2 for Autobrr?
Use it when Autobrr is part of a larger multi-drive download/media stack. The drive bays, broader application headroom and faster local networking—not Autobrr alone—justify the upgrade.
Can Autobrr control download clients on another server?
Yes. Autobrr's feature documentation says one instance can communicate with multiple torrent and Arr clients on remote servers, which can keep the automation host lightweight.
What sources and further reading informed this Autobrr hardware guide?
Autobrr's official Docker and installation pages establish the persistent path, port and SQLite/PostgreSQL guidance. The project repository and SQLite source show current database behavior and tuning. A managed-container provider offers a third-party 1 vCPU / 256 MB / 512 MB-ideal sizing example, which is treated only as external deployment guidance. The ZimaOS App Store confirms Autobrr remains packaged for ZimaOS. None of the official Autobrr sources publishes a numerical CPU or RAM minimum.
