NoctHost

Blog / Tutorials

Monitoring a VPS with Netdata Without It Eating the Box

By the NoctHost TeamAugust 31, 20266 min read

Netdata is the monitoring tool people fall in love with on first sight. You install it, open the dashboard, and there's every metric on the machine updating once per second in real time — CPU per core, disk I/O, every network interface, memory, running processes, and whatever services it auto-detected, all charted, all live, zero configuration. It's genuinely beautiful and it tells you things about your server you didn't know you could see.

Then someone tells you it's heavy, and you get nervous about running it on a small box. That reputation is half-earned. Out of the box Netdata is greedy — it collects everything, every second, and keeps a lot of history in RAM. On a 4 GB server you'll never notice. On a 1 GB server you'll notice. The fix isn't to avoid it; it's to tell it to calm down, which takes about ten minutes.

Install it, then immediately look at what it costs you

The maintainers' kickstart script is the least painful way in, and it keeps itself updated:

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh && sh /tmp/netdata-kickstart.sh

It comes up on port 19999. Before tuning anything, check the honest number: Netdata reports its own resource use, and you can also just look:

systemctl status netdata

On a fresh install with defaults you'll often see it holding a couple hundred megabytes of RAM, most of it the in-memory metrics database. That's the line item that scares people on a 1 GB box, and it's the first thing we'll cut.

The three knobs that matter

Almost all of Netdata's footprint comes down to three things: how often it collects, how much history it keeps, and how many collectors it runs. Turn these down and the same tool that ate 250 MB will sit comfortably under 100.

First, the collection interval. Per-second is Netdata's party trick, but for a server you're watching casually, once every two or five seconds is imperceptibly different and cuts the work proportionally. In /etc/netdata/netdata.conf:

[global]
    update every = 2

Second, and this is the big one, the history. Netdata's default database keeps a generous window of metrics, and on a small box that memory adds up. Cap it. The database is tiered; the simplest meaningful cut is to shrink how much RAM the recent tier is allowed:

[db]
    mode = dbengine
    dbengine tier 0 retention size = 256MiB

That ceiling means Netdata will never blow past it no matter how many charts it's tracking, which is exactly the guarantee you want on a constrained machine. If you barely care about history and just want live numbers, you can go smaller still.

Third, the collectors. Netdata auto-detects and runs a plugin for everything it finds, and on a simple VPS a lot of that is charting things you'll never look at. Each plugin is a little CPU and a little memory. You don't have to hunt them all down, but disabling the obviously useless ones helps. Collectors are toggled in /etc/netdata/netdata.conf under [plugins] and in the per-plugin conf files; the ones worth turning off on a minimal box are anything for hardware or services you don't run.

After any change, restart and re-check the number:

systemctl restart netdata

Be honest about the 1 GB box

Here's the part the enthusiastic tutorials skip. If your VPS has 1 GB of RAM and it's already running your actual workload — a couple of containers, a database, whatever the server is for — then even a tuned Netdata is competing for memory you might need. You can absolutely get it down to a modest footprint with the knobs above, and for many 1 GB boxes that's fine. But if things are tight, be willing to reach for something lighter.

The honest tradeoff:

  • Plenty of headroom (2 GB and up): run Netdata with defaults or a light tune and enjoy it. This is the sweet spot.
  • Tight but manageable (1 GB with room to spare): tune it as above — longer interval, capped history, trimmed collectors — and it's a good citizen.
  • Genuinely constrained (1 GB running a real workload near its limit): consider a lightweight agent that ships metrics elsewhere, or a simple uptime checker, rather than a full per-second dashboard living on the box itself. There's no shame in matching the tool to the box.

The mistake is running default Netdata on a full 1 GB box and then blaming Netdata when memory pressure starts killing your other processes. It told you it collects everything; you just have to tell it not to.

Don't leave the dashboard on the open internet

By default Netdata binds to port 19999 on all interfaces, which means anyone who finds your IP can read a detailed live map of your server — what's running, how loaded it is, when it's busy. That's reconnaissance you're handing out for free. Close it.

The clean approach: bind Netdata to localhost only, then reach it over a VPN into the server. In netdata.conf:

[web]
    bind to = 127.0.0.1

Now the dashboard answers only from the machine itself. If you've got WireGuard into the box already, bind it to the VPN interface's address instead of localhost, and you can open the dashboard from your laptop over the tunnel while the public internet sees nothing:

[web]
    bind to = 10.0.0.1

Use whatever your server's address is on the VPN subnet. Either way, the fix is the same idea — the metrics are for you, so make them reachable only by you. Do not "solve" this by putting the dashboard behind a password on a public port and calling it done; a reverse proxy with auth is better than nothing, but keeping the port off the internet entirely is the version that actually sleeps well. This pairs naturally with running SSH over the same tunnel — one private door for everything administrative.

Spin one up in about a minute

Email signup, pay with crypto, hourly billing. Trying a box costs cents — destroy it when you are done.

Deploy a server

Frequently asked

Is Netdata actually too heavy for a small VPS?
Only with defaults. Out of the box it collects everything per-second and keeps a lot of history in RAM, which is noticeable on a 1 GB box. Raise the update interval, cap the database size, and trim unused collectors, and it drops to a modest footprint that most small servers handle fine.
What's the single biggest thing to change on a small box?
Cap the database memory. The in-memory metrics history is the largest part of Netdata's footprint, so setting a retention size ceiling on the recent tier gives you a hard limit it can't exceed no matter what it's charting.
How do I see the dashboard if I bind it to localhost?
Reach it over a VPN into the server, or use an SSH tunnel: ssh -L 19999:127.0.0.1:19999 you@server then open http://localhost:19999 on your laptop. Both keep the dashboard off the public internet while letting you in.
Netdata versus a simple uptime monitor — which do I want?
Different jobs. Netdata is deep, live, on-box diagnostics: it tells you why the server is struggling right now. An uptime monitor tells you from the outside whether a service is up at all, and pings you when it isn't. Many people run both — a lightweight external check for alerts, Netdata for when you need to dig in.
Does the kickstart install keep Netdata updated?
Yes, it sets up automatic updates by default, so you don't have to chase releases. If you'd rather pin the version, the installer has a flag to disable auto-updates, but for most people leaving it on is the right call.

Keep reading

Tutorials

Uptime Kuma monitoring

Tutorials

Many containers, one VPS

Tutorials

Personal WireGuard VPN