"how to run prometheus grafana docker compose on 2gb vps without running out of memory"

"For prometheus grafana docker compose low memory under 2gb vps optimization 2025, the key is tuning TSDB retention and Grafana background processes. Setting --storage.tsdb.retention.time=7d and enabling --storage.tsdb.wal-compression reduces Prometheus memory usage by 30-40%, while disabling Grafana's alerting workers and image rendering drops its footprint from ~250MB to ~80MB. Adding Docker Compose mem_limit constraints prevents any single container from consuming enough RAM to crash the host."

"why does prometheus use so much memory on a cheap VPS"

"Prometheus keeps two hours of data in its write-ahead log (WAL) before compressing it into TSDB blocks, which alone can consume 200-300MB on a host with 10,000+ active time series. Combined with the in-memory head block, an untuned Prometheus container typically uses 400-600MB of RSS memory by default. This default behavior makes it problematic to deploy on 1-2GB VPS instances without explicit memory optimization flags."

"prometheus grafana docker compose low memory under 2gb vps optimization 2025 best settings"

"The most impactful settings for running this stack on a budget VPS are --storage.tsdb.retention.time=7d to limit data history, --storage.tsdb.wal-compression to reduce WAL size, and Docker Compose mem_limit to cap container memory usage. On the Grafana side, enabling anonymous access and disabling background processes via environment variables reduces its memory floor from roughly 250MB down to 80MB. Together these changes make a full Prometheus and Grafana observability stack viable on a $6/month VPS."

"does grafana use a lot of RAM on a small server"

"By default, Grafana ships with alerting workers, image rendering daemons, and plugin managers all enabled, which pushes its memory usage to around 250MB at baseline. Disabling these unnecessary background processes through environment variables can drop that floor to approximately 80MB, making it much more suitable for low-memory hosts. For a basic dashboard setup on a 1-2GB VPS, none of those default background features are typically required."

"how to set memory limits for prometheus and grafana in docker compose"

"In your Docker Compose file, you can add a mem_limit value under each service definition to cap how much RAM each container is allowed to consume. This prevents a single runaway container, such as an untuned Prometheus instance during a scrape spike, from exhausting host memory and killing other services. Setting these limits is considered a critical safety measure when running a monitoring stack on a 2GB VPS alongside other applications."

Productivity

Prometheus and Grafana on Docker Compose Under 2GB VPS

April 2, 2026 7 min read English

Running a full observability stack on a $6/month VPS sounds reckless. It isn’t — if you know which knobs to turn.

Most tutorials assume you’ve got at least 4GB of RAM and a comfortable cloud budget. But a significant slice of the indie developer and small-team market runs on 1–2GB VPS instances from providers like Hetzner, DigitalOcean, or Vultr. Dropping Prometheus and Grafana onto one of those boxes without tuning is a fast path to an OOM-killed container and a dead dashboard at 2am.

This piece breaks down exactly how to make Prometheus + Grafana on Docker Compose actually work under 2GB — with real configuration values, memory baselines, and trade-off comparisons.

Key Takeaways
An untuned Prometheus container consumes 400–600MB of RSS memory by default — fatal on a 2GB host running other services.
Setting --storage.tsdb.retention.time=7d and --storage.tsdb.wal-compression cuts Prometheus disk and memory usage by roughly 30–40%, per Prometheus project documentation.
Grafana’s memory floor drops from ~250MB to ~80MB when anonymous access is enabled and background processes are disabled via environment variables.
Docker Compose mem_limit constraints prevent a single runaway container from taking down the entire host.

Why a 2GB VPS Is Still the Default for Thousands of Developers

Hetzner’s CX11 (2GB RAM, €3.29/mo as of Q1 2026) and DigitalOcean’s Basic Droplet at $6/month remain the entry points for self-hosted tooling. According to the 2025 Stack Overflow Developer Survey, roughly 38% of developers who self-host monitoring tools do so on instances with 2GB of RAM or less. Budget matters. So does simplicity.

The standard Prometheus + Grafana Docker Compose stack became the de facto monitoring setup for small teams around 2019–2020. Docker Recipes and Last9’s setup guides both show a working three-container stack: Prometheus, Grafana, and a target exporter. Clean, portable, version-controlled.

The problem is that “working” and “memory-efficient” aren’t the same thing. Default Prometheus builds scrape metrics every 15 seconds and store 15 days of data in memory-indexed TSDB blocks. Grafana ships with alerting workers, image rendering daemons, and plugin managers enabled by default — none of which you need for a basic dashboard on a budget VPS.

By 2026, the gap between default configs and production-viable configs on low-memory hosts has gotten wider, not smaller. Both projects have added features. Base memory footprints have grown. The optimization work is on you.

Prometheus Memory: The TSDB Is the Culprit

Prometheus keeps two hours of data in its write-ahead log (WAL) before compressing into TSDB blocks. On a busy scrape target with 10,000+ active time series, that WAL alone can consume 200–300MB. Add the in-memory head block and you’re looking at 400–600MB before you’ve opened a single Grafana panel.

Three flags change this dramatically:

command:
  - '--storage.tsdb.retention.time=7d'
  - '--storage.tsdb.wal-compression'
  - '--storage.tsdb.head-chunks-write-queue-size=0'

wal-compression (available since Prometheus 2.11) reduces WAL size by roughly 35%, according to the Prometheus changelog. Cutting retention from 15d to 7d halves the on-disk block count and reduces the memory needed to index them. On a node with under 1,000 active time series — typical for a small VPS running one app — total Prometheus RSS drops to 80–150MB with these flags set.

Add --web.enable-lifecycle if you want to reload config without a restart. Skip it otherwise. Every enabled feature carries a cost.

This approach can fail when cardinality explodes — more on that below.

Grafana’s Hidden Memory Drains

Fresh Grafana install, default settings, two dashboards: expect 200–300MB RSS. That’s before any user connects. The culprits are the alerting engine, the background stat collector, and the image renderer.

These environment variables cut that footprint significantly:

environment:
  - GF_ALERTING_ENABLED=false
  - GF_EXPLORE_ENABLED=false
  - GF_ANALYTICS_REPORTING_ENABLED=false
  - GF_SECURITY_ALLOW_EMBEDDING=false
  - GF_AUTH_ANONYMOUS_ENABLED=true
  - GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer

Disabling alerting alone drops ~40–60MB if you’re using Alertmanager or don’t need alerting at all. Anonymous viewer access removes session management overhead. According to Grafana Labs’ own performance tuning documentation, these settings reduce idle memory consumption by 30–50% on single-user or read-mostly deployments.

Target: Grafana sitting at 70–90MB idle. That’s achievable.

Docker Compose Memory Limits: The Safety Net

Without mem_limit, a memory leak or spike in either container triggers the Linux OOM killer — which picks victims somewhat randomly. Your SSH daemon might die instead of Prometheus. That’s a bad night.

Spacelift’s Prometheus + Docker Compose guide recommends explicit resource constraints, and the advice holds up:

services:
  prometheus:
    mem_limit: 400m
    mem_reservation: 128m
  grafana:
    mem_limit: 200m
    mem_reservation: 64m

mem_limit is the hard ceiling. mem_reservation is the soft hint Docker uses for scheduling. On a 2GB host running Nginx, a Node.js app, and this monitoring stack, these limits leave ~1GB for your actual workload.

Default Stack vs. Tuned Stack: The Numbers

Metric	Default Config	Tuned Config	Change
Prometheus idle RSS	400–600MB	80–150MB	−65%
Grafana idle RSS	200–300MB	70–90MB	−65%
Combined monitoring overhead	600–900MB	150–240MB	−70%
TSDB disk usage (7d)	~2–4GB	~800MB–1.5GB	−60%
Scrape interval	15s (default)	30s (tuned)	2× reduction
Data retention	15 days	7 days	Halved

Doubling the scrape interval from 15s to 30s cuts Prometheus’s CPU and series write load in half. For infrastructure monitoring — not high-frequency app metrics — 30s resolution is perfectly adequate. According to Prometheus best practices documentation, sub-15s scrape intervals are only warranted for latency-sensitive SLO tracking.

Three Scenarios Worth Walking Through

Scenario 1 — Solo developer, single app, $6 VPS. Run everything on one host: app, Nginx reverse proxy, Prometheus, Grafana. With the tuned config, the monitoring stack uses ~200MB total. That leaves 1.6GB for the app and OS. Set mem_limit on every container so one bad deploy doesn’t cascade.

Scenario 2 — Small team, staging environment. Five microservices, each exposing /metrics. Prometheus scrapes five targets at 30s intervals. Series count stays under 5,000. Memory stays under 200MB for Prometheus. Add a node-exporter container for host metrics — it adds ~20MB RSS. Still comfortable on 2GB.

Scenario 3 — Cardinality explosion. One developer adds a metric with a user ID label. Series count jumps from 2,000 to 200,000 overnight. Prometheus RSS spikes past 1GB, hits mem_limit, gets OOM-killed, restarts in a loop. This is a documented failure mode, not a hypothetical. The fix is --query.max-samples combined with recording rules to pre-aggregate high-cardinality metrics. Prometheus’s recording rules documentation covers this pattern in detail.

The cardinality scenario matters because it’s the most common way a tuned setup stops working. A single mislabeled metric from a new service can undo every optimization above. Monitoring your Prometheus with prometheus_tsdb_head_series as an alert threshold is worth adding before anything else breaks.

What Comes Next

Prometheus 3.x (at 3.1 as of early 2026) has been aggressively reducing memory per series in TSDB. The 3.0 release notes document 30–40% lower memory per active series versus 2.x. If you’re holding on Prometheus 2.x for stability, benchmarking 3.x on a test instance is worth the hour.

Grafana’s Alloy — the OpenTelemetry-native agent replacing Grafana Agent — has a lighter footprint than the full Grafana server for metrics-only pipelines. For teams that need collection without dashboarding on the same host, it’s worth evaluating as a separate collector.

Where to Go From Here

The default configs ship for developer convenience, not resource efficiency. That gap is fixable in about ten minutes.

Pull the default docker-compose.yml from Last9’s or Spacelift’s guides. Apply the TSDB flags and Grafana env vars listed above. Add mem_limit constraints before the first deploy. That’s the whole procedure.

The results: Prometheus TSDB flags cut memory 30–65%. Grafana env vars eliminate 40–60MB of idle background processes. Docker Compose limits prevent cascading OOM failures. Scrape interval at 30s halves write load with minimal fidelity loss.

This isn’t always the answer — if you’re running high-cardinality application metrics with sub-minute SLOs, a 2GB host will fight you regardless of tuning. But for infrastructure monitoring, staging environments, and solo projects, the math works out.

One number determines whether a 2GB host is viable for your stack: your current Prometheus series count. Check prometheus_tsdb_head_series before you deploy. If it’s under 5,000, you’re in good shape. If it’s climbing toward 50,000, plan accordingly.

References

Photo by Conny Schneider on Unsplash