If you run Netdata on one to three machines at home, the local agent dashboard on port 19999 plus the free Netdata Cloud tier covers almost everything you need, and a paid plan rarely earns its keep across three years. Pay only when you need durable multi node views, alert routing that reaches other people, and role based access you can revoke. Self hosting a Netdata parent node is the cheapest route to long retention and one dashboard for every child node, and the price is one always on machine plus a weekend of setup. Bolting Prometheus and Grafana onto Netdata is the most expensive option measured in hours, and it only pays back if you already run that stack for something else.
TL;DR by reader profile:
- Solo dev with one box (Marco, one mini PC running 14 containers): stay on the local agent and the free tier, because a single node needs no aggregation layer and the agent already stores its own history.
- Solo dev with four to six nodes (Priya, a NAS, two VPS and a spare laptop): build a self hosted parent node, since streaming gives you one dashboard and one retention policy without a per node bill.
- Dev who checks metrics from a phone while away (Tomas, on call for his own side project): use the free Cloud tier or a WireGuard tunnel home, because remote reachability is the one thing a local only setup genuinely lacks.
- Dev already running Prometheus and Grafana (Ines, with existing dashboards and recording rules): keep Netdata as a collector and export to your existing stack rather than paying twice for storage and dashboards.
- Dev sharing nodes with other people (Sam, two contractors with root on the same servers): a paid plan is the cleanest answer, since roles, invitations and revocation are exactly what self hosting makes you build by hand.
- Dev with hard data residency rules (Lena, contract work under a strict client policy): parent node only, because it keeps every metric and every alert inside machines you control.
The tradeoff is straightforward: Netdata Cloud sells you remote access, retention and permissions as a subscription, and a parent node buys you the same three things with your own hardware, your own tunnel and your own maintenance hours.
Table of contents
- What does Netdata Cloud actually add on top of the agent you already run?
- What does the free tier stop giving you?
- How much does Netdata Cloud really cost over three years?
- What does a self hosted Netdata parent node cost over the same three years?
- How do you size a parent node for a home server's metric volume?
- How much bandwidth does streaming from child to parent actually use?
- How do the dbengine tiers change your retention bill on a parent node?
- What does bolting Prometheus and Grafana onto Netdata cost you in hours and hardware?
- Which setup gives you alerts that actually reach you, and what do notifications cost?
What does Netdata Cloud actually add on top of the agent you already run?
The agent is not a thin client. Every collector, every chart, every health alarm and the entire time series database run on the machine itself, and http://localhost:19999 serves the full dashboard whether Cloud is connected or not. Netdata Cloud does not collect your metrics a second time. It adds a control plane on top of agents that already work.
A single view across nodes: Cloud stitches your connected agents into one interface, so a chart can span four machines instead of forcing you to open four browser tabs on four addresses.
Reachability without a tunnel: the agent opens an outbound connection to Cloud, so you get remote access without exposing port 19999, forwarding a port on your router, or standing up WireGuard or Tailscale yourself.
Identity and permissions: Cloud is where accounts, invitations, Spaces, Rooms and role assignments live. A standalone agent has no user model at all, so anyone who reaches the port sees everything.
Centralised alert state: the agent evaluates health entities locally and can send notifications by itself, but Cloud aggregates active alerts from every node and routes them through integrations configured once for the whole Space.
Fleet metadata and history: node inventory, which agents are online, and alert history that outlives the individual agent's database.
The distinction matters for cost. If you disconnect Cloud tomorrow, collection, retention and local alarms keep running unchanged. What you lose is the aggregation layer, and that layer is exactly what a self hosted parent node also provides.
What does the free tier stop giving you?
Start with what it does not touch. The free Community tier places no cap on collection frequency, no cap on the metrics the agent gathers, and no cap on how long your own machine retains them. Retention is decided by netdata.conf and your disk, not by your plan. The limits sit in the control plane instead.
Advanced notification integrations: email and basic delivery are available without paying, while the routed integrations most teams want, PagerDuty and Opsgenie among them, sit on paid plans. The agent itself can still fire notifications directly through health_alarm_notify.conf, which is the free workaround.
Granular roles: free Spaces give you a small set of role options. Fine grained separation, the kind you need when a contractor should read dashboards but never silence an alarm, is a paid feature.
Extended alert and event history in Cloud: the window Cloud keeps for alert transitions and audit events is shorter on the free tier. Your agent keeps its own health log regardless, so this is convenience, not data loss.
Support commitments: community support versus a contractual response time is a real difference, and it is worth close to nothing when the only person on call is you.
Two things to check before you budget. Plan boundaries move, so read the current pricing page rather than a blog post, this one included. And every paid capability above is a permissions or routing feature, not a monitoring feature. Nothing you pay for makes the agent see more. That single observation is what makes the three year arithmetic in the next section lean the way it does.
How much does Netdata Cloud really cost over three years?
Netdata Cloud paid plans bill per node per month, so your three year total is not one number, it is a multiplication. Thirty six months times your node count times the plan rate, plus whatever your node count does over that period. Rates change, so pull the current figure from the pricing page and run the arithmetic yourself. The shape of the bill matters more than today's rate, because the shape is what makes it grow.
| Cost driver | How it scales | Effect on a 36 month total |
|---|---|---|
| Node count | Linear, and a node is any claimed agent | Six nodes cost six times one node, every month, forever |
| Container hosts | One Docker host is one node, not one per container | Cheap if you consolidate, expensive if you spread services across boxes |
| Ephemeral nodes | Test VMs and rebuilt machines can each claim a slot | Silent creep, so prune stale nodes in the Space regularly |
| Billing period | Annual commitment usually beats month to month | Locks the rate for twelve months and removes one variable |
| Plan tier | Step function, not linear | Adding one contractor who needs a restricted role can move the whole Space up a tier |
Two habits keep the total honest. Run netdata claim deliberately rather than baking a claiming token into every image you build, otherwise a rebuild loop quietly adds billable nodes. And decide your node count for year three, not year one, because a home lab that starts at two machines rarely stays at two. That growth curve is precisely what a parent node absorbs for free.
What does a self hosted Netdata parent node cost over the same three years?
A parent node is a normal Netdata agent that accepts streamed metrics from children. There is no licence, no node count and no billing period. The costs are real, they are just paid in hardware, watts and hours instead of invoices.
Hardware, if you need any: if you already keep a NAS or a mini PC running all day, the marginal cost is close to zero and you skip this line entirely. If you buy a box for the job, divide the purchase price by 36 months to get the monthly figure you actually compare against a subscription.
Electricity, which is the only truly recurring cost: measure idle draw with a plug meter, then multiply watts by 8,760 hours per year, by three years, by your tariff per kWh. A parent aggregating a handful of children sits near idle most of the time, so the delta over a machine you already run is small.
Disk for retention: the parent stores every child's history in its own dbengine files, so its storage footprint is roughly the sum of the fleet. Sizing that properly is section seven's job.
Setup hours, paid once: generate an API key with uuidgen, configure stream.conf on the parent and on each child, open the streaming port between them, verify the children appear. Budget an evening for the first one and minutes for each additional child.
Ongoing maintenance: package updates, an occasional config migration, and watching that children reconnect after reboots.
That is the whole bill. Notice that node count appears nowhere in it, which is the structural difference from a per node subscription.
How do you size a parent node for a home server's metric volume?
Do not guess the fleet total. Measure one child, then multiply. Query http://localhost:19999/api/v1/info on a typical machine and read back how many charts and dimensions it actually collects. A quiet VPS and a Docker host running 20 containers differ by an order of magnitude, because every container, every network interface and every mounted filesystem adds dimensions.
CPU on the parent scales with ingested dimensions, not with node count: four small children can be lighter than one busy container host. Streaming ingestion itself is cheap, since the parent is storing points rather than running collectors.
Machine learning is the biggest optional CPU cost: the parent can train anomaly models for streamed children as well as itself. If the parent is a low power box, set enabled = no under the [ml] section of netdata.conf on the parent and leave detection running on the children instead.
RAM follows tier0 caching: the dbengine holds recent pages in memory before flushing them to disk, so memory use tracks the total dimension count across the fleet. Give the parent headroom rather than trimming it to the exact working set.
Disk wants sustained small writes, not raw capacity: the dbengine flushes continuously. An SSD, even a modest one, behaves far better here than a spinning disk shared with media files.
Start with two children, then watch the parent monitor itself: Netdata ships a Netdata Monitoring section that charts its own CPU, memory and dbengine behaviour. Add the rest of the fleet only once that section looks flat.
Size for your year three node count, then stop. Over provisioning a parent is the one place this setup starts costing subscription money.
How much bandwidth does streaming from child to parent actually use?
The honest answer is that you must measure it, but you can predict its shape precisely. A child sends one value per dimension per collection interval, continuously, over a single persistent TCP connection. Bandwidth is therefore dimensions multiplied by frequency, and nothing else. A quiet node with few dimensions produces a trickle. A Docker host with hundreds of container dimensions at one second resolution produces a steady, measurable stream.
Compression is on by default and does most of the work: the streaming protocol compresses the connection, configured under the [stream] section of stream.conf. Leave it enabled. Metric streams are highly repetitive, so they compress well.
Collection frequency is the single biggest lever: raising update every from 1 to 2 in netdata.conf on a child roughly halves what it sends. You lose per second granularity on that node, which for a backup NAS matters far less than for a database host.
Reconnection triggers replication, not a silent gap: when a child comes back after downtime, it backfills the missing window to the parent. Expect a burst well above the steady rate, proportional to how long the link was down.
Trimming collectors trims the stream permanently: disabling collectors you never look at removes their dimensions from both the parent's disk and the wire.
Measure it where it counts: watch the network interface chart on the child, or run iftop against the parent's address, and read the real number for your fleet.
This only becomes a cost line if a child lives on a metered connection or a VPS with an egress allowance. On a LAN, it is free.
How do the dbengine tiers change your retention bill on a parent node?
Netdata does not store one copy of your history. The dbengine writes three tiers, each downsampling the one before it, and each with its own retention setting in the [db] section of netdata.conf. This is why a parent holding months of data for six children stays manageable. The arithmetic per dimension per day makes the point immediately.
| Tier | Default granularity | Points per dimension per day, and what it buys |
|---|---|---|
| Tier 0 | 1 second | 86,400 points: the forensic detail you want for the last incident, and the overwhelming majority of your disk usage |
| Tier 1 | 1 minute | 1,440 points: sixty times cheaper, still fine for spotting a memory leak developing over a week |
| Tier 2 | 1 hour | 24 points: effectively free, and the right resolution for capacity planning across months |
| All three combined | Mixed | The parent serves whichever tier matches the zoom level of the chart you are viewing |
The tuning move is obvious once you see the ratio. Shorten tier 0 retention and lengthen tiers 1 and 2. Keeping seven days of per second data plus a year of hourly data costs a fraction of keeping per second data for a year, and you will almost never zoom to one second resolution on something that happened in March.
Set retention per tier by size, by time, or by both, and the dbengine enforces whichever limit it hits first. Setting a size cap is the safer habit on a home server, because it guarantees Netdata cannot fill the disk that everything else depends on.
What does bolting Prometheus and Grafana onto Netdata cost you in hours and hardware?
Netdata exposes /api/v1/allmetrics?format=prometheus on port 19999, so wiring it into Prometheus is a scrape target in prometheus.yml and nothing more. The integration is easy. The stack around it is what costs.
You now run three services instead of one: Prometheus, Grafana, and in practice Alertmanager, since Grafana alerting or Alertmanager is what turns a query into a notification. Each has its own config, its own upgrade cadence and its own breaking changes to read about.
You store everything twice: the agent keeps its dbengine tiers and Prometheus keeps its own TSDB, on the same disk if this is one home server. Prometheus defaults to 15 days retention, so budget capacity for both databases rather than assuming the scrape replaces local storage.
You lose per second resolution unless you fight for it: Prometheus commonly runs a 15 second scrape_interval. Dropping that to 1 second across a Netdata export multiplies series volume hard, which is exactly the cardinality problem the tiered dbengine was designed to avoid.
You rebuild dashboards by hand: Netdata auto generates charts for every collector it finds. Grafana gives you a blank canvas. That is a genuine advantage if you want a curated view, and a genuine cost measured in evenings if you just wanted the charts you already had.
You rewrite alerts in a second language: health entities on the agent become PromQL rules plus routing config, maintained separately.
The verdict is conditional. If Prometheus already runs for other services, exporting Netdata into it is sensible and nearly free. If it does not, this is the most expensive of the three options and the only one where the recurring cost is your attention.
Which setup gives you alerts that actually reach you, and what do notifications cost?
Every option evaluates alarms the same way, because health entities run on the agent regardless of what sits above it. The difference is what happens when the alerting machine is the machine that failed. A single agent watching only itself cannot tell you it lost power. That blind spot, not feature lists, should drive this decision.
A lone agent covers threshold alerts and nothing else: it fires on high disk usage or a stopped service, and it goes silent on the failure mode you most want to hear about.
A parent node closes the gap for children: it evaluates alarms on streamed data and notices when a child stops reporting, so a dead VPS produces an alert instead of silence. You configure delivery once on the parent rather than on every node.
Netdata Cloud closes the same gap from outside your network: the outbound connection means Cloud sees a node go unreachable even if your whole house loses power, which a parent sitting in that house cannot do.
Free delivery channels do most of the work: Discord, Slack, Telegram and ntfy all accept webhooks directly from the agent, cost nothing, and reach your phone. Reload after editing with netdatacli reload-health.
Paid channels are the real notification cost: SMS through a provider bills per message, and a PagerDuty seat can exceed what you spend on monitoring itself.
The pragmatic setup for one person is two independent paths. Let Netdata alert on thresholds, then run a separate reachability check from somewhere else entirely, a free tier uptime service or an Uptime Kuma instance on different hardware. Redundant alerting costs nothing and catches the failure a single system structurally cannot.
Top comments (0)