Originally published at rajesh.medampudi.com/blog/lgtm-for-small-teams
You don't need Datadog. You also don't need the full microservices Grafana LGTM build that Grafana's own scaling docs describe. For a team of two to ten engineers running a handful of services, the realistic minimum Grafana LGTM stack is four backends in their simplest mode — Loki, Tempo, Mimir, Grafana — fed by one agent, Grafana Alloy, with all three data stores pointed at one S3 bucket. That is the whole thing. Everything past that is scale you don't have yet.
I am writing this because most observability advice is written for the company that already has the problem the advice solves. The Grafana scaling guide assumes you're ingesting terabytes. The Datadog sales motion assumes someone else is paying. The blog posts that show you a forty-service Helm install assume you have a platform team. None of that is the small team. The small team has a few boxes, a deploy that breaks at the wrong time, and no budget line for a per-host SaaS bill that triples the month traffic spikes. This is the build for that team.
Why not just pay Datadog
Because the bill does not stay where the quote put it.
Datadog's list pricing, as of June 2026, is $15 per host per month for Pro infrastructure monitoring billed annually, and $31 per host per month for APM on top of that. Logs are metered separately: $0.10 per GB ingested, plus $1.70 per million log events indexed for 15-day retention. The billing model meters your host count hourly, drops the top 1% of hours, and bills the whole month at the peak of what's left — so a traffic spike sets your bill for the month, not just the hour (Datadog pricing, accessed June 2026).
Run the arithmetic for a small but real setup. Ten hosts with APM is 10 × ($15 + $31) = $460/month before a single log line. Add modest logging — say 100 GB ingested a month with a few million indexed events — and you're past $500, climbing. The pattern every cost breakdown reports is the same: teams find the actual bill two to three times the initial estimate once logs, APM, and custom metrics compound (Last9 Datadog pricing breakdown, 2026). That is $6,000 to $18,000 a year to know whether your own servers are healthy. For a small team that number is not a rounding error. It's a hire. (At real scale the gap gets absurd — I watched a self-hosted stack run an 85% cheaper than the bill on a 6 TB/day platform.)
Grafana Cloud is the honest middle option and I won't pretend it isn't. The free tier is genuinely useful — 10,000 active metric series, 50 GB of logs, 50 GB of traces, 14-day retention, three users, $0 (Grafana Cloud free tier, accessed June 2026). If you fit inside that, use it and stop reading; self-hosting buys you nothing. The moment you don't fit — more series, more log volume, longer retention — you're on usage pricing: $8 per 1,000 active series above the free 10k, $0.50/GB for logs and traces above 50 GB, plus a $19/month platform fee on Pro (Grafana pricing, accessed June 2026). That scales with your data, which is fairer than per-host, but it still scales. Self-hosting trades that recurring bill for one fixed cost: your S3 storage and the box the stack runs on. For a small team that already runs its own infrastructure, that trade is usually worth making.
What each letter actually does
LGTM is four open-source backends. The names are dull on purpose. Here is the one-line job of each, and nothing more, because the small team doesn't need the architecture lecture.
- L — Loki. Your logs. Loki indexes only labels (service, host, level), not the full text, which is why it's cheap to run and cheap to store. You query it in Grafana with LogQL.
- G — Grafana. The single pane of glass. Dashboards, queries, alerts. The only component your team looks at directly. The other three are plumbing behind it.
- T — Tempo. Your traces. When a request crosses three services and one of them is slow, Tempo is how you find which one. It stores traces by ID and links out from your logs.
- M — Mimir. Your metrics. It's a long-term, horizontally-scalable store for Prometheus metrics — the thing that holds your CPU, memory, request-rate, and latency time series for as long as you tell it to.
Loved this acronym? Nobody does. But the mapping is clean: logs, dashboards, traces, metrics. Three signals plus the screen you read them on.
The one piece that changed: Alloy, not Promtail
If you read an LGTM tutorial written before 2025, it tells you to install Promtail for logs and maybe Grafana Agent for metrics. Don't. Both are dead.
Grafana Agent and the Agent Operator went into long-term support on 9 April 2024 and reached end-of-life on 1 November 2025 (Grafana, Agent-to-Alloy FAQ, accessed June 2026). Promtail was deprecated into LTS on 13 February 2025, with EOL following (Grafana Alloy/Loki migration docs, accessed June 2026). The replacement for all of them is Grafana Alloy — a single agent that collects logs, metrics, traces, and profiles, built as an open-source distribution of the OpenTelemetry Collector and 100% OTLP-compatible (Grafana, Agent-to-Alloy FAQ, accessed June 2026).
This is the rare deprecation that simplifies your life. Instead of running Promtail for logs and Agent for metrics and wiring up something else for traces, you run one Alloy binary on each host. It scrapes Prometheus metrics, tails logs, receives OTLP traces, and ships all three to the right backend. One config, one process, one thing to upgrade. If you're starting fresh today, start on Alloy. If you're on Promtail, Grafana ships a converter that translates your config automatically — but you should move, because the LTS clock has already run out.
The realistic minimum: monolithic mode, one S3 bucket
Here is the part the scaling docs bury. Loki, Tempo, and Mimir can each run in monolithic mode — all of their internal components inside a single process, one binary per backend. The microservices mode that splits each into a dozen Deployments exists for the companies ingesting terabytes a day. You are not that company — and if you ever become it, that build is a different post (). Monolithic is the correct default and it's officially supported, not a hack.
Grafana's own Loki docs put a number on it: monolithic mode is suitable for read/write volumes up to roughly 20 GB per day (Grafana Loki install docs, accessed June 2026). Twenty gigabytes of logs a day is a lot of logs for a small team — most won't get close. Tempo runs monolithic the same way, needing only an object store as its external dependency (Grafana Tempo docs, accessed June 2026). Mimir's monolithic mode runs every required component in one process for exactly this getting-started case (Grafana Mimir docs, accessed June 2026).
The architecture in one sentence: Alloy on each host ships to three single-binary backends, all three write their blocks to one S3 bucket, and Grafana reads from all three.
[ host ] → Alloy ─┬─ logs ──→ Loki ─┐
├─ metrics → Mimir ─┼──→ one S3 bucket
└─ traces → Tempo ─┘
↑
Grafana reads all three
S3 is the load-bearing decision. All three backends are designed to use S3-compatible object storage as their long-term store — AWS S3, Google Cloud Storage, Azure Blob, or self-hosted MinIO if you want zero cloud dependency (Grafana Mimir storage docs, accessed June 2026). This is what makes self-hosting cheap and durable. Your compute stays small and stateless-ish; your data lives in object storage that costs a couple of cents per GB-month and never fills a disk. You can run the stack on local filesystem for a demo, and the docker-otel-lgtm image does exactly that for local development (Grafana OpenTelemetry docker-lgtm docs, accessed June 2026) — but for anything you intend to keep, point all three at one bucket on day one. Retrofitting storage later is the migration you don't want.
Sizing: what it actually takes to run
This is where I have to be careful and honest, because the resource footprint depends entirely on your volume, and anyone who quotes you a flat "2 cores, 4 GB" number without asking your ingest rate is guessing.
What the documentation establishes:
- Mimir's resource use scales with active series and samples ingested. With near-zero traffic, baseline utilisation is very low; Grafana recommends a 1:4 CPU-to-memory ratio (1 core per 4 GB) as you grow (Grafana Mimir hardware requirements, accessed June 2026). Run with ~50% headroom over steady state to absorb peaks.
- Loki is light at small scale — community guidance puts an instance under light load at roughly 1 CPU core and a few hundred MB of RAM (Grafana Loki sizing, accessed June 2026). Its index-labels-only design is why.
- Tempo's external dependency is just the object store; in monolithic mode its footprint tracks trace ingest volume.
My honest read, from running LGTM myself: each backend in single-process mode is genuinely light. On my own stack I run Loki capped at 1 core / 2 GB, Tempo at 1 core / 2 GB, and Mimir at 2 cores / 4 GB per replica — and that's a deliberately over-provisioned ceiling, not the steady-state draw, which sits well under it at low volume. For a small team running one replica of each instead of an HA set, that's the whole LGTM stack fitting comfortably on a single modest node — a handful of cores and 8–16 GB of RAM — with all the durable data offloaded to S3. One caveat in the other direction: my own deployment is a multi-node, three-replica HA cluster, not the single box this post recommends — so treat the per-component numbers as real, and the single-box framing as the right starting shape, not a claim that I run it that minimally. Start small, watch Mimir's memory as your series count climbs, and scale the one box up before you ever consider splitting into microservices. Most small teams never need to split.
The setup is not free of effort — anyone who tells you self-hosting observability is a one-afternoon job is selling something. Expect real time configuring Alloy pipelines, retention, and S3 lifecycle rules — wiring the agents, getting multi-tenant scoping right, and tuning retention per signal is where the hours go, not a single afternoon. But it's a one-time cost against a recurring bill, and the recurring bill is the one that grows while you sleep.
When to NOT self-host
Conviction cuts both ways. Self-hosting is wrong for you if:
- You fit inside Grafana Cloud's free tier. 50 GB logs, 50 GB traces, 10k series, 14-day retention, three users, $0. If that's you, self-hosting buys you operational burden and saves you nothing. Use the free tier.
- You have nobody to own it. Observability that nobody maintains rots into dashboards that lie. If there is no one on the team who will own the stack's upgrades and retention, pay someone — SaaS or a consultant — to own it for you.
- Your problem is compliance retention, not cost. If you need certified long-term retention with audit guarantees, that's a different build with different constraints.
For everyone else — the small team that already runs its own boxes, has someone who can own it, and is watching a Datadog quote climb — the four-backend monolithic LGTM stack on one S3 bucket is the right amount of observability. Not the enterprise build. Not the SaaS bill. The realistic minimum that actually tells you when your systems are sick.
That's the playbook. Loki, Grafana, Tempo, Mimir. One Alloy agent. One bucket. One box. Scale it when the volume forces you to, and not one component before.