Most monitoring setups fall apart fast. You SSH in, run top, maybe df -h. You still can’t explain why the server “felt slow” at 02:13.
If you run Netdata on a VPS, you get per-second visibility into what’s happening. That includes CPU pressure, RAM churn, disk latency, network spikes, and process-level detail.
You get this without standing up a full observability stack.
This spotlight covers Netdata as a self-hosted monitoring dashboard for website and app operators. You’ll see who it’s for, what it can replace, and how to deploy it cleanly with Docker Compose.
We’ll also cover HTTPS, access controls, backups, and low-drama updates.
Why run Netdata on a VPS instead of “just checking logs”
Logs tell you what already happened. Netdata shows what’s happening right now, with enough context to act quickly.
That matters if you’re running:
- WordPress and WooCommerce stores that spike during campaigns and cron runs
- APIs that slow down intermittently because the database is contending
- Background workers where one runaway process can starve the node
- Multi-tenant VPS setups where you need evidence for what consumed CPU and I/O
Netdata is strongest at fast diagnosis. You can spot swap climbing, open memory pressure charts, then jump into “Apps” to see which processes are allocating.
You don’t need to build Grafana dashboards first.
Open-source spotlight: Netdata (what it is, license, and who it fits)
Netdata is an open-source, real-time performance and health monitoring tool. You run an agent on your server and view metrics in a web UI.
It collects system and application metrics (CPU, load, RAM, disk I/O, network, containers, web servers, databases). It can also trigger alerts.
Netdata is released under the GNU General Public License v3.0 (GPLv3). This matters if you plan to modify and redistribute it.
For typical self-hosting, it’s simple. Deploy it and use it.
Netdata is a good fit if you:
- Need immediate visibility for a single VPS or a small fleet
- Want to stay self-hosted and keep telemetry under your control
- Prefer a UI that’s useful without days of dashboard work
If you need long-term retention, heavy log analytics, and cross-service tracing, Netdata can integrate with that setup.
You don’t need any of it to get value on day one.
A quick comparison: Netdata vs hosted monitoring services
Hosted monitoring is convenient. For small teams, it isn’t always the right default.
Here’s the real trade-off:
- Netdata (self-hosted): You control where the data lives, cost scales with your VPS, and monitoring stays available even during third-party outages. You also own patching and access control.
- Hosted SaaS monitoring: Faster to start, often better for multi-account org workflows, and usually includes managed retention and alert routing. You trade privacy and ongoing per-host costs.
For many operators, the decision comes down to friction. If you already run a VPS or dedicated server, adding Netdata on your own infrastructure is a straightforward way to stop guessing.
Resource planning: what to provision before you deploy
Netdata runs comfortably on most production VPS plans. Overhead depends on your workload and which collectors you enable.
- Small VPS (single website/app): 1 vCPU, 1 GB RAM works, but 2 GB feels better if you also run databases and containers.
- Busy VPS (multiple sites, DB, cache): 2 vCPU, 4 GB RAM is a comfortable baseline.
- Disk: Netdata’s local database uses disk for retention. Even small instances should reserve a few GB for monitoring data plus logs.
If monitoring competes with the workload, treat that as a sizing signal.
For predictable performance, consider a HostMyCode VPS so you can scale CPU/RAM without changing your architecture.
Deployment approach: Docker Compose on Ubuntu or Debian
You can install Netdata directly on the host. Docker Compose often keeps upgrades and rollbacks cleaner.
It’s also a good fit if you already run apps in containers.
The outline below assumes Ubuntu 24.04+ or Debian 12+ on a VPS, with Docker installed.
If you want a reference for general “Docker + Nginx + TLS” patterns, our Umami guide uses the same building blocks: Nginx TLS reverse proxy for a container app.
1) Create directories and a dedicated Docker network
sudo mkdir -p /opt/netdata
cd /opt/netdata
sudo docker network create proxy || trueThe proxy network lets your reverse proxy container (Nginx or Caddy) talk to Netdata.
It also helps keep Netdata from being exposed directly to the public internet.
2) Docker Compose file
Create /opt/netdata/docker-compose.yml:
services:
netdata:
image: netdata/netdata:stable
container_name: netdata
hostname: netdata
pid: host
network_mode: host
restart: unless-stopped
cap_add:
- SYS_PTRACE
- SYS_ADMIN
security_opt:
- apparmor:unconfined
volumes:
- netdata-config:/etc/netdata
- netdata-lib:/var/lib/netdata
- netdata-cache:/var/cache/netdata
- /etc/passwd:/host/etc/passwd:ro
- /etc/group:/host/etc/group:ro
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /etc/os-release:/host/etc/os-release:ro
volumes:
netdata-config:
netdata-lib:
netdata-cache:Why host networking? It’s the simplest way to give Netdata accurate host-level metrics.
It’s especially helpful for networking and processes.
If you prefer bridge mode, you can run it there too. Expect a bit more tuning to get the same fidelity.
3) Start Netdata
sudo docker compose up -d
sudo docker compose psBy default, Netdata serves on http://YOUR_SERVER_IP:19999.
Don’t leave it there. Put it behind HTTPS and restrict access.
Reverse proxy + HTTPS: secure access the boring way
Netdata is an admin tool. Treat it like one.
The clean pattern is: Netdata listens locally, your reverse proxy terminates TLS, and you add an authentication layer.
If you want a full Let’s Encrypt walkthrough, follow our current TLS guide: Configure HTTPS with Let’s Encrypt on a VPS.
Option A: Nginx reverse proxy with HTTP Basic Auth
This option is straightforward and reliable. It’s not fancy, but it avoids a common mistake.
Don’t expose a monitoring dashboard on the open internet.
Install Nginx and tools:
sudo apt update
sudo apt install -y nginx apache2-utilsCreate a password file:
sudo htpasswd -c /etc/nginx/.htpasswd netdata-adminCreate an Nginx server block at /etc/nginx/sites-available/netdata:
server {
listen 80;
server_name netdata.example.com;
location / {
proxy_pass http://127.0.0.1:19999;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}Enable the site and reload:
sudo ln -s /etc/nginx/sites-available/netdata /etc/nginx/sites-enabled/netdata
sudo nginx -t
sudo systemctl reload nginxThen issue TLS with Certbot (Nginx plugin):
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d netdata.example.comTip: If you already use Caddy for your other apps, Caddy’s automatic HTTPS is a clean fit.
We have a Caddy-focused reverse proxy guide if you prefer that style: Caddy reverse proxy on a VPS.
Lock it down at the firewall too
Even behind Nginx, don’t expose port 19999 publicly. With host networking, Netdata binds on the host.
Block the port, and allow only HTTP/HTTPS.
With UFW:
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 19999/tcp
sudo ufw enable
sudo ufw statusIf you want the full checklist for UFW on a web server, use: Set Up UFW Firewall on Ubuntu for a Web Server.
Alerting: make it useful, not noisy
Dashboards are reactive. Alerts keep you from learning about downtime from customers.
Netdata ships with many health checks. You’ll get better results by tuning the few you’ll actually act on.
A practical starter set for website/app operators:
- CPU steal (on virtualized hosts): sustained steal can explain “slow but not busy” behavior
- Disk space + inode usage: alert before deploys and logs fill disks
- RAM pressure and swap activity: “free RAM” is less useful than sustained swapping
- Network errors: packet drops and retransmits can mimic application latency
Skip alerts for short spikes. Use a duration window (a few minutes) so routine bursts don’t wake you up.
For a broader monitoring + alerting pattern that pairs nicely with Netdata, see: build alerts with Netdata + uptime checks.
If you want an external “is it up?” view, our Uptime Kuma post is a good companion: Self-Host Uptime Kuma on a VPS With Nginx HTTPS.
Backups: what to save (and what not to bother with)
Netdata stores configuration and a local metrics database. You usually don’t need every metric forever.
Instead, optimize for a fast recovery. Keep a sensible local history and move on.
If you deployed with the Compose file above, your state lives in Docker volumes. Back up these:
netdata-config(configuration)netdata-lib(database and metadata)
The cache volume is optional.
Volume backup example (tar to a backup directory)
Create a backup folder and run:
sudo mkdir -p /var/backups/netdata
# Backup config
sudo docker run --rm \
-v netdata-config:/data:ro \
-v /var/backups/netdata:/backup \
alpine sh -c "cd /data && tar -czf /backup/netdata-config.tgz ."
# Backup lib (metrics DB)
sudo docker run --rm \
-v netdata-lib:/data:ro \
-v /var/backups/netdata:/backup \
alpine sh -c "cd /data && tar -czf /backup/netdata-lib.tgz ."Store backups offsite. A backup on the same VPS is better than nothing, but it’s not disaster recovery.
If you want a tested DR approach, follow our runbook-style guide: Disaster recovery tutorial (2026).
Safe updates: how to upgrade Netdata without surprises
Updates are where “simple monitoring” can get fragile. Containers help because you can pin tags and roll back quickly.
A conservative update flow:
- Back up the Netdata volumes (at least
netdata-config). - Pull the latest stable image.
- Restart the stack.
- Open the UI and confirm collection continues.
cd /opt/netdata
sudo docker compose pull
sudo docker compose up -d
sudo docker logs --tail=50 netdataIf you use Nginx basic auth, confirm you can still log in and that charts populate.
If something breaks, roll back by re-deploying the previous image tag.
To make that easy, pin it explicitly in docker-compose.yml once you’ve tested.
Common pitfalls (the ones that waste your time)
- Leaving port 19999 public: Always proxy it behind HTTPS and block direct access.
- Assuming “low CPU” means “no problem”: Disk I/O latency and memory pressure can hurt performance while CPU looks calm.
- No baseline: Spend 10 minutes on a normal day. Learn what “healthy” looks like for your stack.
- Alert fatigue: Disable noisy alarms early. Keep only what you’ll act on.
If you’re already fighting disk usage issues (especially on Docker hosts), fix the root cause first.
This guide is a solid checklist: Fix a full Linux VPS without downtime.
Where Netdata fits in a real hosting setup
Netdata works best next to the workloads you care about. That includes Nginx/Apache, PHP-FPM, MariaDB/PostgreSQL, Redis, and your app containers.
If you support client sites, it also tightens the support loop. You can point to charts and timestamps instead of trading guesses.
For agencies and multi-site operators, separating concerns often pays off:
- Run websites on one VPS (or a cluster of them).
- Run monitoring on a small separate VPS, or at least lock it behind VPN/basic auth.
If you’d rather not handle OS patching, Docker updates, and security hardening yourself, managed VPS hosting is often the clean trade.
You keep root-level control, but routine maintenance stops eating your weekends.
If you’re planning to run Netdata for production diagnostics, start with a VPS that gives you headroom for spikes and background jobs. A HostMyCode VPS gives you predictable resources, and managed VPS hosting can handle patching and baseline hardening while you focus on the application.
FAQ
Is Netdata safe to expose on the internet?
Not directly. Put it behind HTTPS on a reverse proxy and require authentication. Also block port 19999 at the firewall so only localhost can reach it.
Can I run Netdata alongside WordPress, MariaDB, and Redis on the same VPS?
Yes. On small instances, watch RAM and disk I/O. If you see swapping during traffic peaks, upgrade to more memory rather than disabling monitoring.
Does Netdata replace Grafana?
Not really. Netdata is excellent for real-time troubleshooting and built-in dashboards. Grafana is better for building curated dashboards across multiple data sources and long-term reporting.
What should I back up for Netdata?
Back up configuration and the local database volume if you care about preserving history. If you only care about recreating the setup, backing up config is usually enough.
Summary: a practical reason to run Netdata
If you operate websites and applications, you don’t need “more graphs.” You need answers while the incident is still unfolding.
Netdata delivers live metrics, clean drill-downs, and enough signal to separate CPU trouble from disk, memory, or network issues.
Deploy it behind HTTPS, lock it down, back up the small amount of state you actually need, and keep upgrades routine.
If you want a stable base for always-on monitoring, start with a reliable VPS from HostMyCode and scale as your stack grows.