Prometheus and Grafana on a VPS: A Monitoring Stack That Runs in 512 MB of RAM

“Prometheus and Grafana need a dedicated server” is one of the most persistent myths in VPS monitoring. The pair is usually associated with sprawling Kubernetes clusters, but a deliberately sized Prometheus + Grafana setup runs comfortably on a 1 GB VPS and can even fit in 512 MB if you make a few honest trade-offs. This guide walks through installing the stack on a small VPS, the exact settings that keep memory and disk in check, and the handful of alerts that actually matter for a single-node workload.

What the stack actually costs

Before tuning anything, know your baseline. The four components of a minimal stack are Prometheus itself, node_exporter, Grafana, and optionally Alertmanager. On a freshly installed Debian or Ubuntu VPS the resident set sizes look roughly like this:

Component	Typical RSS	Notes
prometheus	80–150 MB	Grows with scrape targets and retention
node_exporter	15–30 MB	One process per host, very stable
Grafana	90–180 MB	More with many dashboards and plugins
alertmanager	20–40 MB	Optional if you alert from Grafana directly

Total: roughly 250–400 MB for the whole stack. On a 2 GB VPS that is a non-event. On a 512 MB VPS it is survivable, but only if you apply the sizing rules in the next section.

Install in five commands

On Debian 12 / Ubuntu 24.04 all three core components are in the official repositories, which means they arrive as properly managed systemd services:

sudo apt update
sudo apt install -y prometheus prometheus-node-exporter grafana
sudo systemctl enable --now prometheus node_exporter grafana-server

Verify each service is listening before moving on: curl -s localhost:9090/metrics should return Prometheus metrics, and Grafana answers on localhost:3000. Nothing is exposed to the internet at this point, which is exactly what we want.

Sizing knobs that matter on a small VPS

Four settings separate a lean monitoring stack from one that OOM-kills your web server:

• Scrape interval. The default 15 s interval is overkill for a single host. 45–60 s cuts Prometheus CPU and memory roughly in half, and you will not notice the difference on any alert that matters.
• Retention. Set --storage.tsdb.retention.time=15d (or 7 d on a 512 MB box) via a systemd drop-in. Long-term history is what a hosted service is for, not a small VPS.
• Scrape targets. Scrape only node_exporter and your own services. Every extra target multiplies memory.
• Grafana extras. Disable analytics reporting and uninstall plugins you do not use; Grafana’s memory footprint tracks its plugin count.

Disk usage follows retention almost linearly. As a rough guide, a single node_exporter target with default metrics uses roughly 0.5–1.5 GB for 7 days of history at a 60 s scrape interval — well within reach of any VPS with a 20 GB disk.

A minimal prometheus.yml

global:
  scrape_interval: 60s
  evaluation_interval: 60s

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['localhost:9100']

Apply it with sudo systemctl reload prometheus. If you later add a database or web server exporter, add one job per service and keep the scrape_interval inherited from the global setting.

Three dashboards that matter

Resist the urge to install a 100-panel community dashboard. On a single-node VPS three views cover 95% of real questions: a CPU overview (usage, steal, load average), a memory view (available, swap in/out, PSI pressure), and a disk view (space used per mount, I/O latency). Prometheus and node_exporter expose every metric you need for these under the node_ prefix, and Grafana’s query builder handles the rest without any plugin.

The five alerts worth setting

On a small VPS the list of alerts that justify their noise is short:

• Disk space above 80% — the most common cause of dead small VPSes.
• Memory pressure — high PSI or swap thrash, not raw usage.
• CPU steal above 10% sustained — a noisy neighbour is eating your quota.
• Failed systemd unit — catches a crashed service in seconds.
• Certificate expiry — alert 14 days before a TLS cert expires.

Alertmanager is the classic route, but on a small box Grafana’s built-in alerting (contact points, no extra process) is lighter and perfectly adequate.

Wrap it in TLS and move on

Bind Grafana to 127.0.0.1 and front it with a reverse proxy that terminates TLS, then access dashboards over HTTPS only. If monitoring a single VPS feels like overhead, remember that the alternative is discovering a full disk at 3 a.m. — and that the same VPS can host a full production workload while the stack above idles in the background, consuming less memory than a single browser tab.

If you are shopping for hardware to run this on, compare providers on our VPS comparison table to see which plans give you the RAM headroom for monitoring plus your application.

Ready to try it? InterServer’s VPS plans include generous RAM allocations, and the stack in this guide runs on even their smallest tier alongside a live web application.