You add a second LXC container to run some app, and a week later your Proxmox host feels sluggish. Which container is doing it? The built-in Summary tab on the node gives you a couple of graphs updated every few seconds, and that's usually not enough to catch a process that spikes for ten seconds and disappears. That's the gap Netdata fills.
Netdata is a free, open-source monitoring agent that shows you what a Linux system is doing right now, down to the second, with almost no setup. You install one script, wait a couple of minutes, and you've got a dashboard with thousands of metrics already collecting: CPU per core, memory, disk I/O, network throughput, even which processes are eating your RAM. No database to configure, no query language to learn first.
This guide walks through installing Netdata inside its own LXC container on Proxmox VE 9.2, so it stays isolated from your host and from whatever it's watching. By the end you'll have a live dashboard on your network, and you'll understand what it's actually doing under the hood — not just which buttons to click.
What You Will Learn
- What Netdata is, and how it differs from Prometheus/Grafana or Zabbix
- Why running it inside a dedicated LXC container is the safer choice over installing it on the Proxmox host
- How to create a lightweight Debian 13 container for it
- How to install Netdata with the official kickstart script
- How to open the dashboard, read the important graphs, and lock it down with a password
- What to do when the install fails, the container runs out of RAM, or the dashboard won't load
What Is This Feature?
Netdata is a monitoring agent — a small program that runs on a Linux machine, reads system and hardware statistics every second, and serves them up as an interactive web dashboard on port 19999. It was built by a company of the same name and has been open source since 2016.
The pitch that matters for a beginner: you don't design dashboards, you don't define what to collect, and you don't set up a separate database server. Netdata auto-detects what's running on the machine — disks, network interfaces, systemd services, even Docker containers if you have them — and starts charting all of it immediately after install. Every chart updates once per second by default, which is what "real-time" actually means here, as opposed to the 15- or 30-second intervals typical of Prometheus.
If you've read our guide on monitoring Proxmox VE with Prometheus and Grafana, this is a different tool solving a different problem. Prometheus pulls metrics from the Proxmox API on a schedule and is built for watching a whole cluster over weeks and months. Netdata lives on one machine, updates every second, and is built for answering "what is happening on this box right now."
Why Would You Use It?
Three real situations where Netdata earns its keep in a homelab or small deployment:
A container feels slow and you don't know why. Netdata's per-process view shows exactly which process is hammering the CPU or writing to disk at this moment, not five minutes ago. The built-in graphs on the Proxmox node summary can't do that — they're aggregated and delayed.
You want alerts without setting up an alerting stack. Netdata ships with hundreds of sensible alert thresholds already configured — disk filling up, RAM under pressure, a service that stopped responding — and it can email or push a notification the moment one trips. You don't write the rules yourself unless you want to.
You're not ready for Prometheus. Setting up a PVE exporter, a Prometheus server, and Grafana dashboards is a genuinely useful skill, but it's also an afternoon of configuration. Netdata gets you a working, detailed dashboard in about ten minutes. Plenty of homelabbers run both — Netdata for instant answers, Prometheus for long-term trends — and that's a reasonable setup once you outgrow the basics.
One thing worth being upfront about: Netdata by default keeps only a few hours to a couple of days of history in RAM, not months of data on disk. If you need six months of capacity-planning graphs, that's Prometheus territory, not Netdata's.
Prerequisites
- A working Proxmox VE 9.x host (this guide was written against 9.2, built on Debian 13 "Trixie"). The steps are nearly identical on 8.x.
- Root or an account with permission to create LXC containers, either through the web GUI or the shell.
- A Debian 13 or Ubuntu 24.04 LXC template downloaded in Proxmox. If you've never done this, go to your node, open local storage, click CT Templates, then Templates, and download debian-13-standard.
- At least 1 CPU core, 512 MB of RAM, and 4 GB of disk space free for the container. Netdata itself is light, but give it a little headroom.
- Outbound internet access from the container, since the install script downloads packages from Netdata's servers.
- About 10 minutes.
A quick note before you start: this guide installs Netdata inside its own LXC container rather than directly on the Proxmox host. Proxmox's own documentation is explicit that you shouldn't install third-party packages on the host system — it can pull in dependency changes that conflict with Proxmox's own tightly pinned package versions and leave apt upgrade in a bad state. A dedicated container avoids that risk entirely and costs you almost nothing in resources.
Step-by-Step Tutorial
Step 1: Create the LXC container
In the Proxmox web interface, click Create CT in the top-right corner. Work through the wizard with these settings:
- Hostname: something like
netdataormonitor - Template: debian-13-standard
- Disk: 4 GB is plenty
- CPU: 1 core
- Memory: 512 MB, with 512 MB swap
- Network: DHCP is fine, or set a static IP if that's how you run your homelab
Leave Unprivileged container checked. Netdata doesn't need root-level host access to monitor the container it lives in, and running unprivileged is the safer default for anything exposed to your network.
Once the wizard finishes, select the new container in the left-hand tree and click Start.
Step 2: Open a console and update the container
Click Console on the container, log in as root with the password you set during creation, and run:
apt update && apt full-upgrade -yThis pulls the current package list from Debian's repositories and applies any pending updates. A fresh template is sometimes a few weeks old, so this step avoids installing Netdata against outdated system libraries.
Step 3: Install curl (if it isn't already there)
apt install -y curlThe debian-13-standard template usually ships with curl already, but this makes sure. The install script in the next step needs it to reach Netdata's servers.
Step 4: Run the Netdata kickstart script
This is the official installer, maintained by the Netdata project:
curl https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh
sh /tmp/netdata-kickstart.shThe script detects that you're on Debian, pulls in the correct native package, sets up a netdata system user, and enables the systemd service. On a 1 vCPU container with a decent connection this takes two to four minutes. You'll see a progress log scroll by — that's normal, let it finish.
Partway through, the installer asks whether you want to connect this node to Netdata Cloud, a free hosted service for viewing multiple Netdata agents in one place. You can say no here and add it later; it isn't required for the local dashboard to work.
Step 5: Confirm the service is running
systemctl status netdataYou're looking for active (running) in green. If you see that, Netdata is already collecting metrics and serving the dashboard.
Step 6: Open the dashboard
Find the container's IP address (it's shown on the Proxmox Summary tab for that container, or run ip a inside the console). Then, from any browser on the same network, go to:
http://<container-ip>:19999You should land straight on the Netdata dashboard, already populated with live charts. No login screen, no setup wizard — that's by design.
Step 7: Restrict access to the dashboard
Right out of the box, anyone who can reach port 19999 on your network can view the dashboard, and it does expose real detail about your system. For a homelab behind a firewall that's often an acceptable risk, but if you want a password gate, the cleanest option is putting Nginx or Nginx Proxy Manager in front of it with basic auth — we cover setting that up in our Nginx Proxy Manager guide. If you'd rather not expose it to your LAN at all, bind it to localhost only and reach it over an SSH tunnel instead — slower to access, but nothing listens on the network.
Commands Explained
| Command | What it does |
|---|---|
apt update | Refreshes the local list of available packages and their versions from Debian's repositories. Doesn't install anything by itself. |
apt full-upgrade -y | Installs the newest versions of every installed package, including ones that need other packages removed or replaced to upgrade cleanly. The -y skips the confirmation prompt. |
curl ... -o file | Downloads a file from a URL and saves it locally instead of printing it to the screen. Here it saves Netdata's install script before running it, so you can inspect it first if you want. |
sh netdata-kickstart.sh | Runs the downloaded install script, which figures out your OS, grabs the right Netdata package, and configures the systemd service. |
systemctl status netdata | Shows whether the netdata service is currently running, along with its last few log lines. This is the first thing to check when something looks wrong. |
systemctl restart netdata | Stops and starts the Netdata service again. Useful after changing a config file under /etc/netdata. |
Common Errors
"This site can't be reached" when opening port 19999. Almost always one of three things: the container's firewall is blocking the port, you typed the wrong IP, or Netdata isn't actually running yet. Check systemctl status netdata first before touching anything else.
Kickstart script exits with a permissions error. You're probably not running it as root inside the container. Unprivileged LXC containers still give you a root shell inside the container itself — check with whoami, and if it says anything other than root, prefix the commands with sudo.
Dashboard loads but graphs are flat or empty. This usually means the container was just created and Netdata hasn't collected enough samples yet. Give it 30-60 seconds and refresh. If it's still flat after a couple of minutes, check journalctl -u netdata -n 50 for errors from individual collector plugins.
"Failed to fetch" errors in the browser console. This shows up if you're accessing the dashboard through a reverse proxy that isn't forwarding WebSocket connections. Netdata's live-updating charts rely on a WebSocket connection, and a proxy configured for plain HTTP only will break that even though the page itself loads.
Troubleshooting
If the container feels unresponsive after install, check memory first. Netdata's default retention keeps a few hours of per-second data in RAM, and on a container with only 512 MB that can matter. Run free -m inside the container. If memory is maxed out, either bump the container's RAM allocation in the Proxmox GUI (Hardware tab, no reboot needed for a running container in most cases, though a restart is cleaner) or reduce Netdata's retention by editing /etc/netdata/netdata.conf and lowering the dbengine multihost disk space MB value, then running systemctl restart netdata.
If the install script can't reach get.netdata.cloud at all, that's a networking problem, not a Netdata problem. From the container, run ping 1.1.1.1 to confirm basic connectivity, then ping get.netdata.cloud to check DNS resolution specifically. If ping to the IP works but the hostname doesn't resolve, your container's DNS server (set during creation, or in /etc/resolv.conf) is misconfigured.
If you deleted the container and started over and now port 19999 seems to return an old dashboard, that's almost always your browser serving a cached page from the old container's IP if you reused it. A hard refresh (Ctrl+Shift+R) usually clears it up.
For anything deeper, Netdata writes its own logs to /var/log/netdata/, separate from the systemd journal, and they're usually more specific about which collector is failing and why.
Best Practices
Give the container a static IP or a DHCP reservation on your router. Dashboards you bookmark are annoying to lose track of every time the container reboots and grabs a new address.
Don't expose port 19999 directly to the internet. If you want remote access, put it behind a reverse proxy with authentication, or better, behind a VPN like Tailscale or WireGuard. The dashboard has no built-in login by default, and it reveals real information about your infrastructure.
Set a memory limit that fits your retention needs, not the other way around. If you want a full day of second-by-second history, plan for closer to 1-2 GB of RAM on the container rather than fighting the default settings on 512 MB.
If you're running more than two or three containers or VMs, consider Netdata's free Cloud tier to view them all from a single pane instead of bookmarking five separate dashboard URLs. It's optional, and the local dashboard works fine without it, but it saves a lot of tab-switching once your homelab grows.
Skip installing Netdata straight on the Proxmox host, even though it's technically possible. The isolation a dedicated LXC container gives you is nearly free, and it keeps Proxmox's own package management untouched.
Frequently Asked Questions
Does Netdata slow down the system it's monitoring?
Barely. Typical overhead is well under 5% of one CPU core on a lightly loaded system. You'll notice the RAM usage from data retention before you notice any CPU impact.
Can Netdata monitor the Proxmox host itself, not just this container?
Not directly from inside an LXC container — an LXC container is isolated from most host-level hardware sensors by design. To monitor the Proxmox host's own hardware (temperatures, host-wide disk I/O), you'd install a separate Netdata agent on the host, which brings back the same package-conflict caution mentioned in the Prerequisites section. Most homelabbers instead run one Netdata container per VM or container they care about.
Is Netdata free?
The agent itself, which is what this guide installs, is fully open source and free with no limits. Netdata Cloud has a free tier for personal use with some caps on node count and retention, and paid tiers aimed at businesses monitoring larger fleets.
How is this different from the graphs already built into Proxmox?
Proxmox's built-in graphs are aggregated at longer intervals and don't break usage down per-process. Netdata updates every second and can show you exactly which process is responsible for a CPU or I/O spike as it happens.
Can I uninstall it cleanly if I change my mind?
Yes — since it's isolated in its own container, the simplest removal is deleting the container from Proxmox. If you installed Netdata directly on a machine and want to remove just the software, the kickstart script supports an --uninstall flag.
Conclusion
Ten minutes and one script gets you a real-time view into a machine that the Proxmox summary page just can't provide. It won't replace Prometheus and Grafana if you're managing a cluster over the long term, and it isn't trying to — Netdata's job is answering "what's happening right now," and it does that job well with almost no configuration.
Start with one container, get comfortable reading the dashboard, and add more as you find yourself wanting the same visibility elsewhere. It's cheap enough in resources that there's rarely a reason not to.