If you’ve ever SSH’d into a server and thought, “Okay… but what is it actually doing right now?”, that’s basically the moment Netdata starts making sense.

Netdata gives you real time monitoring with surprisingly nice dashboards. CPU, RAM, disk, network, Docker, systemd services, containers, temps, load averages, weird spikes at 3:12am. All of it. And it’s fast. Like, you refresh and you see the chart move.

In this guide, I’ll walk you through installing Netdata on an Ubuntu 24.04 server, getting the dashboard working, locking it down a bit, and making sure it survives reboots. Step by step, no guesswork.

What you need before installing

Not much.

  • A server running Ubuntu 24.04
  • SSH access with a sudo user
  • Port access for Netdata (by default it serves on 19999)
  • About 10 minutes, maybe less

If your server is behind a firewall (it should be), we’ll handle that too.

Step 1: Update your server first

I always do this before installing anything. Keeps the dependency weirdness away.

bash sudo apt update sudo apt -y upgrade

Optional but sometimes helpful, reboot if a kernel update happened:

bash sudo reboot

SSH back in after reboot.

Step 2: Pick an install method (and why)

Netdata gives you a few ways to install:

  1. Netdata kickstart script (recommended by Netdata, easiest, usually latest)
  2. Ubuntu packages (simpler, but can lag behind on versions depending on repo)
  3. Docker (nice for containerized environments, slightly different vibe)

For Ubuntu 24.04 server, the kickstart script is the usual winner. You get current builds and it sets up the service properly.

That’s what I’m using below.

Step 3: Install Netdata using the official kickstart script

Run this command:

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

You’ll see a bunch of output. It installs dependencies, downloads Netdata, sets up a systemd service, and starts it.

If everything goes well, at the end you should see something that hints Netdata is running and listening on port 19999.

Quick check: is the service running?

bash sudo systemctl status netdata --no-pager

You want to see active (running).

Also check the port:

bash sudo ss -tulpn | grep 19999

You should see LISTEN with something like 127.0.0.1:19999 or 0.0.0.0:19999 depending on how it’s configured.

Step 4: Open Netdata in your browser

Netdata’s local dashboard is served over HTTP on port 19999.

So if your server IP is 203.0.113.10, you’d go to:

http://203.0.113.10:19999

If you’re on a cloud provider and this doesn’t load, 99 percent of the time it’s a firewall/security group issue.

Which is fine. Let’s handle firewall properly.

Step 5: Allow port 19999 (UFW)

First check if UFW is enabled:

bash sudo ufw status

If it says Status: inactive, you might be using cloud firewall rules instead, or nothing at all. Still, UFW is a good baseline.

If UFW is active, allow Netdata:

If you want Netdata accessible from anywhere (not recommended long term):

bash sudo ufw allow 19999/tcp

A better approach is to allow access only from your IP. Replace YOUR_IP with your actual IP address:

bash sudo ufw allow from YOUR_IP to any port 19999 proto tcp

Then reload the UFW settings:

bash sudo ufw reload

Now try loading the dashboard again.

Cloud firewall note

If you’re on AWS, DigitalOcean, Hetzner, GCP, etc., you might need to open the port there too. Even with UFW configured perfectly, it still won’t load if the provider blocks it upstream.

So just keep that in mind if you’re stuck.

Step 6: Bind Netdata to localhost only (recommended)

Here’s the honest thing. Exposing Netdata straight to the internet on port 19999 is not my favorite idea.

A better pattern would be to bind Netdata to 127.0.0.1 only and then put Nginx in front of it, adding basic auth and HTTPS for security.

Even if you don’t do the full Nginx setup today, binding to localhost is still a solid quick win.

Check what it’s currently bound to

Look at the port output again:

bash sudo ss -tulpn | grep 19999

If it shows 0.0.0.0:19999, it means it’s listening on all interfaces.

Update Netdata config to bind to localhost

Edit the main config file:

bash sudo nano /etc/netdata/netdata.conf

If the file is very small or missing sections, that’s normal because Netdata generates defaults internally. You can create what you need.

Add (or edit) this line under the [web] section:

bind to = 127.0.0.1

Save and exit.

Restart Netdata with the following command:

bash sudo systemctl restart netdata

Confirm it’s now only accessible from localhost:

bash sudo ss -tulpn | grep 19999

Now you won’t be able to access http://server-ip:19999 it directly anymore, which is expected.

The next step involves reverse proxying, a process that can also help in scenarios where you’re looking into deploying more complex applications like a self-hosted AI coding assistant on a GPU cloud platform, as detailed in this blog post.

Step 7: Put Nginx in front (reverse proxy)

If you want a clean URL like https://monitor.yourdomain.com And you want authentication, Nginx is the simplest route.

Install Nginx

bash sudo apt update sudo apt -y install nginx

Allow Nginx through UFW (if you use UFW):

bash sudo ufw allow ‘Nginx Full’

Create an Nginx site config for Netdata

Create a new config file:

bash sudo nano /etc/nginx/sites-available/netdata

Paste this (replace monitor.yourdomain.com with your domain):

nginx server { listen 80; server_name monitor.yourdomain.com;
location / {
    proxy_pass http://127.0.0.1:19999/;
    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_http_version 1.1;
    proxy_set_header Connection "keep-alive";
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable it:

bash sudo ln -s /etc/nginx/sites-available/netdata /etc/nginx/sites-enabled/netdata

Test Nginx config:

bash sudo nginx -t

Reload:

bash sudo systemctl reload nginx

Now if DNS is pointing correctly, your Netdata should be reachable at:

http://monitor.yourdomain.com

Still no HTTPS yet, but it should load.

Step 8: Add password protection (basic auth)

You probably want this. Even if it’s just you.

Install Apache tools (for htpasswd):

bash sudo apt -y install apache2-utils

Create a password file:

bash sudo htpasswd -c /etc/nginx/.htpasswd netdataadmin

It’ll prompt you for a password.

Now edit your Nginx config:

bash sudo nano /etc/nginx/sites-available/netdata

Add these lines inside the location / { ... } block:

nginx auth_basic “Restricted”; auth_basic_user_file /etc/nginx/.htpasswd;

So the final location block looks like:

nginx location / { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd;

proxy_pass http://127.0.0.1:19999/;

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_http_version 1.1;
proxy_set_header Connection "keep-alive";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-Proto $scheme;
}

Test and reload again:

bash sudo nginx -t sudo systemctl reload nginx

Now you’ll get a username/password prompt before the dashboard loads.

Step 9: Add HTTPS with Let’s Encrypt (Certbot)

This is the “okay now it’s actually decent” step.

Install Certbot:

bash sudo apt update sudo apt -y install certbot python3-certbot-nginx

Request the certificate:

bash sudo certbot --nginx -d monitor.yourdomain.com

Follow the prompts. Pick the redirect option if it asks. Makes life easier.

After that, visit:

https://monitor.yourdomain.com

You should see the same Netdata dashboard, now encrypted.

Step 10: Make sure Netdata starts on boot

It usually does automatically, but we’ll confirm:

bash sudo systemctl is-enabled netdata

If, for some reason, it’s not enabled:

bash sudo systemctl enable netdata

Step 11: A couple of quick Netdata sanity checks

Netdata is running, dashboard loads, great. But I like to verify a few things.

Check health alarms (alerts)

Netdata has built-in alarms. On the left sidebar in the UI, there’s usually an “Alarms” or notification area. Click around. If you see alarms firing constantly, it might be legit, or it might be that your server is tiny and swapping, which is also legit, just annoying.

Check resource overhead

Netdata is efficient, but still. On very small VPS instances, everything matters.

In the dashboard, find Netdata’s own charts and see how much CPU and RAM it’s using. Usually it’s modest.

If it feels too heavy, you can tune retention, disable some collectors, etc. That’s more advanced, but possible.

Common problems (and the fixes)

1) “I installed it, but the dashboard won’t load.”

  • Check service status: bash sudo systemctl status netdata –no-pager
  • Check port listening: bash sudo ss -tulpn | grep 19999
  • If listening only on 127.0.0.1, you can’t access it via the server IP directly. Use Nginx reverse proxy or SSH tunnel.

2) “It loads locally but not from my laptop.”

That’s almost always a firewall.

  • UFW rule missing
  • Cloud firewall/security group missing
  • ISP blocks random ports (less common)

3) “Nginx shows 502 Bad Gateway.”

That means Nginx can’t reach Netdata.

Confirm Netdata is bound to localhost and running: bash curl -I http://127.0.0.1:19999

If curl fails, Netdata is down or bound differently.

If curl works, you are wrong (typo), or the Nginx config didn’t reload.

4) “Certbot failed.”

Usually, DNS isn’t set correctly yet.

  • Make sure monitor.yourdomain.com points to your server IP.
  • Wait a few minutes for DNS.
  • Then retry: bash sudo certbot –nginx -d monitor.yourdomain.com

Bonus: Quick SSH tunnel option (if you don’t want to expose anything)

If you just want to view Netdata occasionally and not set up Nginx yet, do this:

On your local machine:

bash ssh -L 19999:127.0.0.1:19999 user@your-server-ip

Then open:

http://127.0.0.1:19999

This is honestly one of the safest quick setups. Nothing exposed publicly. It’s just a tunnel.

Wrapping up

That’s the full setup.

If you want the simplest install, the kickstart script gets Netdata running in minutes. If you want it done properly on a server you care about, bind it to localhost and reverse proxy it through Nginx with auth and HTTPS. It takes a little longer, but you end up with something you’re comfortable leaving online.

And once it’s running, you’ll probably do what I did. Keep a tab open, glance at it when something feels slow, and then go down a rabbit hole of charts. Which, yeah, is kind of the point.

FAQs (Frequently Asked Questions)

1. What is Netdata, and why should I use it on my Ubuntu 24.04 server?

Netdata is a real-time monitoring tool that provides detailed dashboards showing CPU, RAM, disk, network usage, Docker containers, systemd services, temperatures, load averages, and more. It helps you understand what your server is doing at any moment with fast, live-updating charts.

2. How do I install Netdata on an Ubuntu 24.04 server?

The recommended installation method for Ubuntu 24.04 is using the official Netdata kickstart script. You can install it by running: wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh followed by sudo sh /tmp/netdata-kickstart.sh. This installs dependencies, sets up Netdata as a systemd service, and starts it.

3. How can I access the Netdata dashboard after installation?

Once installed and running, Netdata serves its dashboard over HTTP on port 19999. If your server IP is 203.0.113.10, access it via http://203.0.113.10:19999. Ensure that your firewall or cloud provider’s security group allows traffic on port 19999.

4. What steps should I take to secure Netdata access on my server?

It’s best practice to bind Netdata to localhost only by editing /etc/netdata/netdata.conf and setting bind to = 127.0.0.1 it under the [web] section, then restarting the service. For remote access, use a reverse proxy like Nginx with HTTPS and basic authentication instead of exposing port 19999 directly to the internet.

5. How do I configure firewall rules to allow access to Netdata’s port (19999)?

If UFW (Uncomplicated Firewall) is active on your server, allow traffic on port 19999 with sudo ufw allow 19999/tcp for open access or restrict it to your IP with sudo ufw allow from YOUR_IP to any port 19999 proto tcp. Remember to reload UFW (sudo ufw reload). Also, check the cloud provider firewalls, which may block this port separately.

6. What should I do if Netdata’s dashboard doesn’t load despite opening port 19999 in UFW?

If you’ve opened port 19999 in UFW but still can’t access the dashboard, verify if your cloud provider’s firewall or security groups are blocking the port upstream (AWS Security Groups, DigitalOcean Firewalls, etc.). Open port 19999 there as well to allow external access.