Roadmap
Where avuru obs is headed. This is directional, not a commitment — scope and
order shift as we learn. The authoritative technical detail lives in the engine
repo's ROADMAP.md;
this page is the human-readable summary. For what already works today, see
Feature status; for what has shipped, see the
Changelog.
North star
:::tip The wedge A fresh Kubernetes cluster → live service map in under five minutes, zero app changes. Every milestone is judged against this, and it's enforced as a CI gate. :::
v0.1 — the wedge (released 2026-07-15)
The signal tiers we ship for 0.1:
| Tier | Signal | Status |
|---|---|---|
| Full | Service map + RED metrics; trace explorer (waterfall, search) | Shipped |
| Basic | Logs (collection, full-text search, trace_id correlation) | Shipped |
| Lite | Continuous profiling (per-service CPU flame graphs) | Shipped |
| Supporting | Infra metrics (node/pod CPU, memory, network) | Shipped |
Plus the hard promise: an OTLP drop-in replacement — already-instrumented apps migrate by changing only the exporter endpoint, no SDK or code changes.
Milestones toward v0.1
Local stack & ingestion
Shippedmake devcompose stack (ClickHouse + collector + demo app)- OTLP ingest end-to-end; first drop-in e2e test
- Trace explorer, logs, service map & System Status live
Deployable OTLP backend
Shipped- Helm install path; gateway → ClickHouse → hub in-cluster — live
- Sensor DaemonSet: zero-code eBPF traces + RED (OBI), zero-config logs — live
- Service inventory UI (RED per service) — live
Signal depth & correlation
Shipped- Infra metrics & node/pod health dashboards — live
- RED metrics dashboard — live
UI depth
Shipped- Trace waterfall + flamegraph, spans table, statistics, trace graph — live
- Trace comparison (structural diff) — live
- Continuous profiling UI (per-service flame graphs) — live
Gateway build & TTV gate
Shipped- OCB-built minimal collector distro — live
- kind-based time-to-value gate enforcing the sub-5-minute wedge — live
v0.2 — depth and control (released 2026-07-28)
Everything targeted at v0.2 shipped in v0.2.0: secure-by-default authentication with per-project roles and OIDC SSO, the module framework (pick your signals), error tracking with a browser ingest path, service health groups with criticality tiers, alerting webhooks, network health on the service-map edges, the green energy & carbon module, and a CI-proven "safe to leave on" sensor. The project is licensed AGPL-3.0 as of this release. Full detail on the feature status page and in the changelog.
v0.3 — tenancy you can trust (released 2026-07-31)
v0.2 secured the read side; v0.3.0 closes the write side.
Projects became something you administer — create, rename and delete them
from the UI — and per-project ingest keys mean a sender no longer just
claims a tenant: in enforce mode the key decides where its telemetry lands.
Alongside that: a one-click read-only demo, green energy on RAPL-less
cloud VMs, the control-plane groundwork for runtime collection switches, and
the rename of the deploy layer from avuruops to avuruobs (breaking —
see the upgrade guide). Full detail on the
feature status page and in the
changelog.
v0.4 — accounts you can administer (released 2026-08-07)
v0.4.0 finishes the account lifecycle v0.2 began: user
management from the UI — edit a user's name and role grants, reset a password,
delete an account behind a disable-first rule — plus a self-service password
change in Settings → Account, with password operations refused for SSO users
whose credential lives at the identity provider. Reviewing that surface closed
three ways into an account: a local password that could be minted on an
SSO-only account, a login lockout that rotating IP addresses walked straight
past, and an SSO login able to take over a local account's email. On the
operations side, an install whose schema migration never ran now repairs
itself and reports applied-versus-expected schema in Settings → Status; green
no longer takes the sensor down on nodes without RAPL; and login works behind a
reverse proxy that rewrites Host. Full detail on the
feature status page and in the
changelog.
v0.5 — operate it from the UI (released 2026-08-16)
Almost everything you administered needed a values edit and a redeploy; v0.5.0 moves it into the app. Runtime collection control shipped complete: each signal switches on or off from Settings → Collection and the sensor follows in seconds, still default-off behind a narrowly-scoped Role. Service groups are authored in the app, with chart-declared groups read-only and winning name collisions. Settings → Storage and Access show where telemetry lives and who may touch what; the SSO group→role mapping is editable beside the chart's rules; and personal API tokens give scripts and future clients a credential that follows its owner's live permissions. The Dashboard answers "how is the estate doing?" on one screen, the service map carries real health rings, caller-side per-edge latency and shareable filters, and the Nodes screen sorts and filters. OpAMP remains the destination for collection control: status reporting first, remote-config when the upstream grows a client. Full detail on the feature status page and in the changelog.
v0.6 and beyond (directional)
- Wider ingest compatibility: push receivers for the common tracing/metrics/logging wire protocols alongside OTLP, plus forwarding exporters so avuru obs can dual-write during a migration.
- More clients: the hub API is the client-agnostic contract; the SPA is one thin client. A Grafana data source and a CLI are planned, both riding the personal API tokens v0.5 shipped.
- Multi-cluster projects: member projects that aggregate several clusters, per-project retention and system status, and chart component toggles so a secondary cluster installs gateway(+sensor)-only against a shared ClickHouse. Project CRUD and ingest keys shipped in v0.3.
- Richer auto-tagging: map Kubernetes labels/annotations to business tags and filter by them across every signal.
- Storage re-evaluation: ClickHouse stays behind the
storage.Storeinterface; GreptimeDB is slated for re-evaluation mid-2027 without changing hub code.
How this roadmap changes
Open an issue or discussion to propose a change of direction; larger items graduate into an Avuru Enhancement Proposal before implementation. Roadmap edits go through a normal pull request.