Netdata documents memory scaling from collected metrics and database indexes. Highly dynamic container/Kubernetes environments can create far more metric metadata than a simple host.
Container-heavy homelabs and infrastructure platforms.Configuration matérielle requise pour Netdata : processeur, RAM, disque et conservation des métriques
Découvrez les exigences de Netdata en matière de CPU, de RAM, de disque, de rétention, de ML et de relations parent/enfant, puis choisissez le matériel ZimaOS adapté à la surveillance.
Netdata requirements at a glance
Netdata now publishes measured resource requirements. A standalone Agent typically uses 100–200 MB RAM on an empty system and 250–350 MB in production, about 1–5% of one CPU core at default settings and up to 5–20% in production, with roughly 4 GiB of disk under the default three-tier retention configuration. Those figures rise with metric count, retention, Machine Learning and Parent/Child streaming.
- CPU
- Official measured footprint: about 1–5% of a single core with default settings and up to 5–20% in production.
- RAM
- Official measured footprint: 100–200 MB on an empty system and 250–350 MB in typical production.
- Disk
- About 4 GiB by default: roughly 3 GiB metric storage plus metadata. Retention is tiered and configurable.
- Sampling
- Most metrics are collected at one-second granularity. Netdata says increasing the collection interval from one to two seconds can roughly halve collection CPU use.
- Scaling
- More unique metrics, database tiers, Machine Learning and streamed child nodes increase memory/CPU/disk/network requirements. Parent systems should be sized separately.
- Best Zima starting point
- ZimaBoard 2 832 easily covers a standalone Netdata Agent plus normal ZimaOS services. The 1664 or ZimaCube 2 becomes useful when the server acts as a Parent, retains more history or monitors a larger container/homelab estate.
From official requirements to the right setup
Netdata sizing starts from the official baseline and then scales by metric cardinality and retention.
-
Official requirements
Use Netdata's current standalone Agent baseline first: 100–200 MB RAM on an empty system, 250–350 MB in typical production, 1–5% single-core CPU by default and roughly 4 GiB default disk.
-
Confirm your needs
Count collected unique metrics and high-cardinality workloads such as short-lived containers. Netdata documents a direct relationship between unique metrics and RAM, so metric count is more meaningful than host count alone.
-
Leave room to grow
Choose retention and tiers deliberately. The default three tiers consume roughly 3 GiB metric storage plus metadata; longer/larger retention increases disk and can also increase RAM needed to index stored metrics.
-
Run it on ZimaOS
Install Netdata from the ZimaOS App Store, measure collected metric count and Agent footprint, then decide whether to reduce collectors/ML/retention or move to a Parent/Child design before buying more hardware.
Check every playback client
- Standalone Agent versus Parent node
- Number of collected unique metrics
- Docker/container cardinality and churn
- One-second versus slower collection interval
- Database mode and number of tiers
- Retention size/time
- Machine Learning enabled
- Number of streaming Child nodes
Official minimum requirements
Netdata's July 2026 resource-utilization documentation publishes an explicit measured footprint for a standalone Agent.
These official figures are much more useful than old forum estimates. Use 100–200 MB / 250–350 MB RAM, 1–5% / 5–20% of one CPU core and about 4 GiB default disk as the current baseline, then scale from metric count and retention.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU - default | 1–5% of one core | Official measured standalone Agent footprint. |
| CPU - typical production | Up to 5–20% of one core | Depends on metrics, ML, collectors and workload. |
| RAM - empty system | 100–200 MB | Current official measured range. |
| RAM - typical production | 250–350 MB | Current official measured range. |
| Disk - default | About 4 GiB | Approximately 3 GiB metrics across three tiers plus SQLite/alert/metadata overhead. |
| Linux installation privilege | Root required for installation | From current Netdata resource/system requirements. |
When to upgrade your hardware
Upgrade Netdata when metric cardinality, retention or Parent duties—not dashboard rendering alone—create resource pressure.
Unique metric count becomes very large
Long retention and more database tiers consume RAM/disk
The ZimaOS node becomes a Netdata Parent
Netdata says database tiers directly affect memory and retention affects disk/index memory. Long history is therefore an intentional capacity decision.
Users keeping weeks/months/years of local metrics.Parent resource needs scale with Child count, aggregate metrics and retention. Parent sizing can become orders of magnitude larger than a standalone Agent.
Multi-server homelabs centralizing monitoring.Plan hardware growth with confidence
Scale Netdata by reducing unnecessary metrics on edge Agents and concentrating history where it belongs.
Reduce unused collectors before adding RAM
Netdata explicitly recommends disabling unnecessary data collectors because more metrics raise CPU, RAM, disk I/O and disk space.
Lower cardinality first if the extra metrics provide no operational value.Increase the sample interval on constrained systems
Netdata says moving from one-second to two-second sampling can roughly halve collection CPU use.
Trade temporal resolution for lower CPU/disk demand when one-second data is unnecessary.Use Parent/Child streaming for low-resource nodes
Children can run a lighter database mode such as RAM while a Parent stores long-term metrics and performs more work centrally.
Give the Parent the larger RAM/disk budget instead of over-sizing every edge node.Tune retention instead of treating disk growth as a leak
The default three-tier footprint is around 4 GiB and retention is enforced by size/time. More history means intentionally more disk/index overhead.
Use ZimaCube storage only when long Parent retention or broader server storage needs justify it.Can it run on ZimaOS?
Netdata is currently available in the ZimaOS App Store under Productivity and is designed for real-time host/container monitoring.
Install Netdata from the ZimaOS App Store
Use the packaged app to monitor ZimaOS system, storage, network and container metrics.
Open Netdata in the ZimaOS App StoreUse the current official footprint rather than old forum numbers
Netdata's 2026 docs now publish measured CPU/RAM/disk ranges for the standalone Agent.
Read Netdata resource utilizationPlan Parent retention separately
If ZimaOS becomes the Parent for multiple Netdata Children, configure storage/retention from aggregate metric count instead of the standalone 4 GiB baseline.
Read Netdata Parent configuration best practicesChoose Zima hardware for Netdata
A standalone Netdata Agent is small. More powerful Zima hardware is justified when the machine becomes a Parent, retains much more history or also runs a large Productivity/self-hosted stack.
Is Netdata monitoring one ZimaOS host, or acting as a central Parent for multiple systems?
Standalone Agent / normal home server monitoring
ZimaBoard 2 832 has very large headroom over Netdata's 250–350 MB typical production footprint.
- Standalone Netdata AgentZimaBoard 2 832
- Agent plus many Productivity/monitoring appsZimaBoard 2 1664
Parent node, longer retention or larger homelab
Move up for aggregate metric memory, database retention and the wider server workload.
- Multi-drive monitoring/storage ParentZimaCube 2 Standard
- Large Parent and 10GbE-capable homelab serverZimaCube 2 Pro
Netdata's official resource ranges are measured baselines, not fixed maximums. Unique metrics, containers, ML, sample interval, retention tiers and streaming topology can change CPU/RAM/disk needs substantially.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Monitoring one ZimaOS/home server with Netdata. | Standalone Agent, Docker/container monitoring and default retention. |
|
High metric cardinality or turning this host into a Parent can increase RAM/disk needs substantially. | Get Now |
| ZimaBoard 2 1664 | Netdata plus a larger Productivity and observability stack. | More containers, local services and extra monitoring/retention headroom. |
|
16 GB is whole-server headroom; standalone Netdata typically uses hundreds of MB. | Get Now |
| ZimaCube 2 Standard | A monitoring Parent or all-in-one server needing multi-drive retention. | More metrics/children plus storage and other self-hosted workloads. |
|
Choose it for retention/storage and broader server capacity. | Get Now |
| ZimaCube 2 Pro | A larger homelab Parent/observability server. | Many children, heavier retention, databases and high-speed local infrastructure workflows. |
|
10GbE is relevant to the broader homelab/data path; Netdata itself does not require 10GbE. | 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 FAQ topics follow query fan-out around Netdata RAM growth, disk writes, retention, one-second sampling, ML and Parent/Child architecture. Reddit/community discussions were used to identify why users distrust apparent RAM growth, while current official 2026 resource documentation provides the numbers.
How much RAM does Netdata need in 2026?
Netdata's current official guidance says about 100–200 MB on an empty system and 250–350 MB in typical production for a standalone Agent.
Why does Netdata RAM usage grow over time?
More unique metrics and retained metric metadata require more in-memory indexing. Long retention, extra tiers and high-cardinality container workloads can therefore raise memory even if the dashboard itself is idle.
How much disk does Netdata use by default?
About 4 GiB under normal default conditions: roughly 1 GiB for each of three database tiers plus metadata, alert transitions and SQLite files.
How long does the default Netdata retention last?
Current defaults cap each tier at 1 GiB with both size and time limits. Netdata documents roughly 14 days for per-second Tier 0, 3 months for per-minute Tier 1 and up to 2 years for per-hour Tier 2, but the size limit can be reached first depending on metric volume.
Does Netdata's one-second sampling use much CPU?
The official Agent baseline is only about 1–5% of one core by default, but sampling frequency contributes to CPU and disk activity. Netdata says changing from one-second to two-second collection can roughly halve collection CPU.
Does Netdata Machine Learning increase hardware requirements?
Yes. Netdata identifies ML model training as CPU-intensive and also shows ML models contribute to memory at scale. Constrained Child nodes can disable ML and let a Parent handle more of the work.
Should I use Netdata Parent/Child or run full retention on every server?
For a few normal servers either can work. Parent/Child becomes attractive when edge nodes are resource-constrained or you want centralized longer retention; Children can be configured lighter while the Parent carries the larger RAM/disk budget.
Can ZimaBoard 2 832 run Netdata?
Yes. Its 8 GB RAM is far above Netdata's current 250–350 MB typical standalone production footprint and leaves large headroom for ZimaOS and other Productivity services.
What sources and further reading informed this Netdata hardware guide?
Netdata's July 2026 Resource Utilization page is the primary source for the current CPU, RAM and ~4 GiB disk baseline. The dedicated RAM and Disk/Retention pages explain metric-cardinality memory and three-tier retention. Reddit/community discussions were used for fan-out around high memory and RAM-only logging, but older observed values are not substituted for today's official ranges. The ZimaOS App Store confirms the current Productivity package.
