Prometheus Grafana Docker Compose High Memory Fix on 1GB VPS

Running a full monitoring stack on a single 1GB VPS sounds ambitious. It is. But with the right configuration, it’s absolutely achievable — and plenty of production setups do exactly this.

The default Prometheus + Grafana Docker Compose configuration is written for teams with resources to spare. Spin it up on a DigitalOcean Droplet or Hetzner CX11, and within hours your 1GB instance starts thrashing swap. The OOM killer shows up. Containers restart. Your monitoring stack — the thing supposed to tell you when things break — is the thing breaking.

This is a fixable problem. The defaults are wrong for constrained environments, not the architecture itself.

The short version: Prometheus and Grafana both ship with memory settings tuned for servers with 4GB+ RAM. A targeted set of Docker Compose overrides and scrape interval adjustments brings total stack memory consumption below 400MB on a 1GB VPS.

Three specific areas drive most of the memory waste:

1. Prometheus TSDB retention defaults store 15 days of metrics in memory-mapped files — far more than most small deployments need
2. Grafana’s Node.js memory ceiling is uncapped at the container level
3. Docker Compose resource limits are absent by default, letting containers compete unchecked

Key Takeaways

• Default Prometheus retention of 15 days pushes TSDB memory usage past 600MB on busy hosts, per Grafana Labs’ own storage sizing documentation.
• Setting --storage.tsdb.retention.time=7d combined with --storage.tsdb.retention.size=512MB caps Prometheus heap growth at a predictable ceiling.
• Grafana’s memory footprint drops significantly when GF_RENDERING_SERVER_URL and plugin preloading are disabled on low-resource instances.
• Docker Compose mem_limit directives prevent container memory spikes from cascading into full-host OOM events.
• The complete tuned stack runs comfortably within 380–420MB total RAM, leaving real headroom for the host OS and your actual application.

Why the Defaults Are Sized Wrong

Prometheus was built at SoundCloud in 2012 for large-scale infrastructure monitoring. Grafana Labs, which now maintains both projects, targets enterprise deployments in its default configurations. That’s not a criticism — it’s just context. Neither project ships defaults optimized for a €4/month Hetzner VPS.

The grafana/grafana Docker image pulls in a full Node.js runtime plus the Grafana backend. Together, at idle, the container consumes around 150–200MB. Prometheus starts lighter but grows. According to Grafana’s official documentation on Prometheus storage (last updated Q1 2026), TSDB memory usage scales with the number of active time series and the configured retention window. A typical Node Exporter setup generating ~3,000 time series with 15-day retention can push Prometheus past 500MB alone.

Add node_exporter, cadvisor if you’re monitoring containers, and Docker engine overhead — and a 1GB host is already at 85–90% memory utilization before your application handles a single request.

This problem spiked across community forums through late 2025 and into 2026 as Hetzner’s affordable ARM instances attracted a wave of indie developers self-hosting their monitoring stacks. The pattern is consistent: default compose file, works for a day, then the server slows to a crawl.

Prometheus Memory: Retention Is the Lever

Prometheus memory breaks down into three buckets: the WAL (write-ahead log), loaded TSDB chunks, and query execution overhead. The WAL alone defaults to 128MB and isn’t easily compressed. TSDB chunks are where the real variability lives.

Two flags do most of the work:

command:
  - '--storage.tsdb.retention.time=7d'
  - '--storage.tsdb.retention.size=512MB'
  - '--storage.tsdb.wal-compression=true'

retention.time=7d cuts loaded chunk memory roughly in half compared to the 15-day default. retention.size=512MB adds a hard disk ceiling — Prometheus evicts the oldest data when storage hits the cap. WAL compression cuts WAL disk and memory overhead by 20–30%, per Prometheus release notes for v2.20+.

Scrape interval matters too. The default 15s interval triples your time series write rate compared to 45s. For a personal VPS, 45s resolution is more than sufficient. Set it in prometheus.yml:

global:
  scrape_interval: 45s
  evaluation_interval: 45s

This approach can fail when you’re debugging fast-moving incidents. Sub-minute granularity matters during an outage. So if you run this config in a more critical environment, consider bumping back to 15s temporarily during investigations.

Grafana Memory: Disable What You Don’t Need

Grafana’s footprint is surprisingly controllable via environment variables. Several defaults are expensive and unnecessary on a constrained host.

environment:
  - GF_USERS_ALLOW_SIGN_UP=false
  - GF_ANALYTICS_REPORTING_ENABLED=false
  - GF_PLUGINS_ENABLE_ALPHA=false
  - GF_ALERTING_ENABLED=false  # use unified alerting or disable entirely

Disabling the legacy alerting engine alone saves 30–50MB at runtime. And if you’re not using Grafana’s built-in image rendering — most self-hosted setups aren’t — don’t pull grafana-image-renderer into your compose file. That plugin adds another 200MB+ for a headless Chromium instance you probably never open.

Docker Compose Resource Limits: The Safety Net

Without explicit memory limits, Docker lets containers request as much RAM as the host provides. One slow query in Grafana, one backfill in Prometheus, and the host kernel starts swapping aggressively.

services:
  prometheus:
    mem_limit: 512m
    memswap_limit: 512m
  grafana:
    mem_limit: 256m
    memswap_limit: 256m
  node-exporter:
    mem_limit: 64m
    memswap_limit: 64m

Setting memswap_limit equal to mem_limit prevents swap usage entirely for that container — the process gets OOM-killed instead of thrashing swap. On a 1GB VPS, that’s the right tradeoff. A controlled container restart beats a frozen host.

Default Stack vs. Tuned Stack

These figures reflect community-reported measurements from the Prometheus and Grafana GitHub issue trackers (2025–2026) and align with Grafana Labs’ own storage sizing guidance. Your numbers will vary based on time series cardinality, but the relative improvement holds.

The tuned config trades granularity (15s → 45s scraping) and history depth (15 → 7 days) for stable operation. For a single VPS running a personal project or small SaaS, that’s a trade worth making. You can always increase retention once you’ve validated the setup is stable.

Three Deployment Scenarios

Scenario 1 — Solo developer monitoring a single app: Apply all tunings above. Drop cadvisor entirely unless you specifically need container-level metrics. Node Exporter plus Prometheus plus Grafana on the tuned config fits in 350MB comfortably. Your app gets the remaining 550–600MB.

Scenario 2 — Small team, 3–5 services: Keep cadvisor but cap it at 128m memory. Increase retention.time to 10d and watch actual Prometheus memory via the process_resident_memory_bytes metric on its own /metrics endpoint. If RSS stays under 300MB at day 3, you’re stable.

Scenario 3 — You need longer retention: Don’t fight the 1GB limit. Use Prometheus as a short-term buffer (7d) and remote_write to Grafana Cloud’s free tier (10,000 series, 14-day retention as of April 2026). You keep local alerting, offload historical storage, and the memory profile stays predictable.

What to watch: Prometheus v3.x (in RC as of Q1 2026) includes native histogram support and improved TSDB compression. Early benchmarks from the Prometheus GitHub repo show 15–20% lower memory for equivalent workloads. Worth testing when stable releases land.

Where to Go From Here

The fix isn’t a single change — it’s a configuration philosophy. Default settings assume abundant resources. Constrained environments need explicit ceilings at every layer.

Key changes to ship today:

• Set --storage.tsdb.retention.time=7d and --storage.tsdb.retention.size=512MB
• Enable --storage.tsdb.wal-compression=true
• Switch scrape interval to 45s
• Add mem_limit and memswap_limit to every service
• Disable Grafana image renderer and legacy alerting

Over the next 6–12 months, two things should make this easier. Prometheus v3 stable will bring lower default memory consumption. And Grafana Labs has signaled lighter-weight deployment profiles in their roadmap discussions for self-hosted instances. Neither is a reason to wait — these config changes take 20 minutes, and the stability improvement is immediate.

If your scrape interval is still set to 15s on a 1GB host, that’s the first thing to change. Everything else follows from there.

References

1. Prometheus + Grafana Docker Compose - Ready to Deploy | Docker Recipes
2. Monitoring a Linux host with Prometheus, Node Exporter, and Docker Compose | Grafana Cloud documenta
3. Prometheus with Docker Compose: The Complete Setup Guide | Last9

Photo by NASA on Unsplash