Map SSO groups to roles, from the app​

Which SSO group grants which role on which projects was a chart value — auth.oidc.mapping in values.yaml, one helm upgrade per change — so giving a team access meant a deploy. Settings → Access now shows those rules and lets an admin add, edit and delete rules of their own beside them.

• The chart stays the declared base. Its rules render read-only, and on a name collision the chart wins: an authored rule for a group the chart also declares is kept and marked as overridden, with the reason on its row, instead of being silently ignored or refused outright.
• A change applies to that group's next sign-in or token refresh, and reaches every hub replica within about fifteen seconds. That bound is stated in the panel, so a stale read on another replica right after a save is not mistaken for a failed one.
• Reset deletes every rule authored in the app and returns the install to exactly what the chart declares. An install with no identity provider configured never sees the panel — there is nothing for it to map.

Personal API tokens​

The hub API is meant to outgrow the browser — a Grafana data source and a CLI are on the roadmap — but the only credential was a session cookie. Settings → Access now mints personal API tokens: create one, with an optional expiry, copy it once, and send it as Authorization: Bearer avurut_….

• Shown once, hashed forever. Only the SHA-256 of a token is stored; the raw value appears exactly once, at creation. The avurut_ prefix says which kind of credential leaked if one ever shows up in a log.
• A token is its owner, live. It carries no permissions of its own — every request resolves to the owner's current roles and project grants, so disabling a user disables every token they hold, structurally rather than by cleanup.
• No silent downgrade. A bad or expired bearer token is a clean 401, never a fall-through to the anonymous viewer an install may have enabled.
• Revocation is immediate and self-service; a global admin can list and revoke anyone's. The list shows when each token was last used, so a stale credential is visible before it becomes a problem.

• Turn signals on and off from the UI. Settings → Collection became writable: switch OBI traces, logs, infra-metrics, profiling or energy collection, edit the excluded namespaces, and the sensor follows in seconds — no helm upgrade. Off by default; opting in grants the hub a deliberately narrow Role over its own sensor ConfigMaps and DaemonSet, nothing else, and the write-through path is proven end to end against a real cluster in CI.

• Say which services matter, from the app. Health groups are authored in Settings → Groups — name, criticality tier, covered namespaces or services — and apply to the next health read. Chart-declared groups stay read-only and win a name collision; auto-grouping by namespace is unchanged, so nothing disappears while you organize.

• One screen for how the estate is doing. The Dashboard is the landing route: service-group health, live topology beside the firing alerts, and Kubernetes capacity in three bands. Each band follows its module — a band whose module is off simply does not mount — and with service health off the summary falls back to the busiest services rather than inventing a second status model.

• The service map says what is wrong, not just that something is. Node rings now show the service's actual status read from the same rollup the Service Health board uses; edges carry the caller-side p50/p95 that call path actually cost; hovering a node focuses its neighbourhood; and search, a problems-only toggle and a group filter live in the URL, so a narrowed map is a link. The carbon lens moved to a halo so health and gCO2e are visible at once.

• Grant access from the app. The OIDC group→role mapping is now editable in Settings → Access — the chart's rules stay authoritative and an overridden rule says why — and the same tab mints personal API tokens: hashed at rest, shown once, resolving to their owner's live permissions on every request, so disabling a user disables every token they hold.

• Where the data lives, and who can touch it. Settings → Storage and Settings → Access: the ClickHouse connection read-only with per-signal usage and retention shown against the TTL the tables actually enforce, and a permissions matrix the hub derives from its own route guards, so it cannot drift from what is enforced.

• Find a pod on the Nodes screen. Both tables sort by any column and filter by name, namespace or workload; filters live in the URL and counts read "N of M", so a narrowed table cannot be misread as a shrinking cluster.

Security​

• Three green endpoints answered without authentication. GET /api/v1/green/summary, /green/budgets and /green/report were registered without the session middleware, so an install with authentication on served any project's energy and carbon figures to an unauthenticated caller. All three now require the viewer role and honour project grants, and a test asserts over the whole project-data route set. Details in the security note.

Fixed​

• The shared demo account was offered a password form it could never submit. The hub was right to refuse the change — the demo credential is shared and re-keyed on every boot — but the UI was never told. /api/v1/auth/me now states whether self-service rotation applies and why not, and the Account tab renders the explanation instead of the form.

Upgrading from v0.4.x is a normal helm upgrade. Schema migrations 0016–0018 apply automatically (hub.autoMigrate). See the Releases page and the GitHub release.

• Status rings, not error dots. A node's ring is its real health — healthy, degraded, down or idle — read straight from the same dependency-aware rollup the Service Health screen uses. The map no longer re-derives thresholds of its own, so the two screens can't disagree. A service the rollup doesn't cover reads as unknown, never as healthy.

• Real per-edge latency. Edges now carry p50 and p95 measured from the caller's side of the call — what that path actually cost, network and queueing included. That's deliberately different from the p95 a node shows for its own server-side work, and the gap between the two is often the point: in the demo data the node reads p95 200ms while the edge into it reads p95 220ms — the caller paid 20ms the callee never saw. Edges derived from network flows, not spans, simply omit the field rather than show a false zero.

• Hover to focus. Hovering a node fades everything outside its neighbourhood, thickens its edges, and labels each one with rpm, p95, error rate and TCP RTT where measured, arrowheads showing direction without your having to trace the line.

• Filters and controls, all in the URL. Search by name, a "problems only" toggle and a service-group filter — each one lands in the query string, so a narrowed map is a link you can paste to a teammate instead of a screen you describe. Zoom, fit-to-view, re-layout and a legend round it out. The status and group filters only appear when service health is running, since both read its rollup.

• Carbon moved to a halo. The ring was the only border a node had, so the carbon lens now draws its gCO2e as a soft halo around it instead — a node can show its health ring and its carbon halo at once.

• The Dashboard's map gets it too. The compact topology on the Dashboard renders the same component, so it picks up rings and hover focus for free, using health data the Dashboard was already fetching.

One screen, three answers​

• Are my services healthy? A card per service group — the groups you authored in Settings → Groups — with its criticality tier, its status, and the rate, latency and error rate behind that status. Worst status sorts first, so a group in trouble is never the one pushed off the end of the row.

• What is talking to what, and is anything firing? The service map at overview scale, side by side with everything currently alerting. Not a screenshot of the map: the same graph, so a service that goes red here is red there.

• Is the cluster under strain? Nodes, pods, namespaces and workloads at a glance, plus memory utilisation per node, busiest first.

Every card is a link into the screen that explains it. The Dashboard is where you notice; the existing screens are where you investigate.

It works on the install you actually run​

Each band belongs to a module, and a band whose module is off simply isn't there — the screen never shows you a panel it can't fill, and never calls an API your install doesn't run. Turn off service health and the first band falls back to your busiest services rather than disappearing. Run nothing but the core and the Dashboard still opens, with the map and your services on it.

Those fallback cards deliberately carry no health status. Thresholds and critical-dependency propagation belong to the service-health module; inventing a second set of them for this screen would put two different answers to the same question in front of you.

What capacity does and does not claim​

The capacity band reports what the sensor measures. Memory shows a real utilisation bar, because both halves — used and available — are collected.

CPU is reported as cores in use, not a percentage, because no node capacity figure exists to divide by: node metrics come from the kubelet, which does not publish allocatable CPU. A percentage here would have had to invent its own denominator, and a capacity reading you cannot trust is worse than an honest absolute. Each bar carries its number as well as its colour, so nothing on this screen has to be read by hue alone.

See the feature status page for where the Dashboard sits among the other screens.

• Collection is a setting, not a deployment. Settings → Collection switches eBPF traces, logs, infrastructure metrics, profiling and energy collection on or off, and edits the excluded-namespace list. Turn profiling off at 2 a.m. because it is costing you more than it is telling you, and turn it back on in the morning — without touching the chart.

• What the screen shows is what the sensor is doing. It reports the effective configuration: your chart values with the overlay applied, not one or the other. "Reset to defaults" clears the overlay and reconciles the cluster back to exactly what the chart declares — a reset that only forgot the setting would leave the two quietly disagreeing.

• Off by default, and narrow when you turn it on. The feature is gated on collection.runtimeControl.enabled. Opting in grants the hub permission to update its own four named sensor ConfigMaps and patch its own named sensor DaemonSet, in its own namespace — nothing cluster-wide, nothing belonging to anyone else. The hub rolls the sensor using its own annotation and leaves the chart's ownership untouched, so a later helm upgrade behaves exactly as before. With the flag off, nothing changes and no extra permission is granted.

• Verified against a real cluster, not a mock. The Helm smoke gate now installs with the feature on, writes a setting through the API, and asserts it reaches the sensor's configuration and rolls the DaemonSet — then resets and asserts the cluster comes back. A change that is saved but never reaches the sensor is the failure that matters here, and the gate is built to catch exactly that.

Configuration lives in the chart under collection.runtimeControl. See Kubernetes setup for the flag, and modules for how each signal is gated.

What was exposed​

For any project named in the request header, without signing in:

• per-service energy in watt-hours and carbon in gCO2e,
• monthly carbon budget usage,
• the CSRD-ready report export.

The routes are read-only, so nothing could be changed through them. But the data is a fair map of what an estate runs and how hard it works — service names, relative load, and the shape of a workload over time.

Nothing else was affected: every other signal route — traces, logs, metrics, service map, health, alerting, error tracking, infrastructure — was already behind the session middleware and enforcing per-project grants.

Why it happened​

The routes were wired with the bare handler wrapper rather than the guarded one, so no identity was ever attached to the request. The per-project scope check then treats "no identity" as "authentication is switched off" — the branch that exists so an auth.enabled=false install keeps working — and allowed the request through.

Am I affected?​

You are if all of these hold:

• the green module is enabled (it is off by default, so an install that never turned it on was never exposed),
• authentication is enabled, and
• the hub's API is reachable by someone you would not grant a viewer role.

An install where the hub is only reachable inside the cluster was not exposed to anyone who could not already reach far more.

The fix​

All three routes now require the viewer role and honour per-project grants, exactly like every other signal. Upgrade to a build containing this change.

A test now asserts that every project-data route answers 401 without a session, rather than checking them one at a time — the gap survived because nothing had ever asserted over the whole set. It was found while indexing every route's guard to build a permissions view for Settings, which is the same idea applied to the product: derive what the rules are from what the server enforces, instead of writing them down twice.

• Sort by any column. Nodes by name, CPU, memory, network or pod count; pods by name, namespace, workload, node, CPU or memory. Nodes stay in name order by default, so the roster does not rearrange itself between refreshes, and busiest-first is one click away. Network sorts on send and receive together — ranking on receive alone would file a send-heavy node as quiet.

• Filter as you type. Nodes by name; pods by name, namespace or workload, plus a namespace picker that appears once there is more than one namespace to choose between. Nothing waits on a query: the rows are already in the browser.

• A filtered view is a link. The filter lives in the URL, like every other view here, so you can send a colleague the exact table you are looking at rather than describing it.

• Counts that cannot mislead. With a filter active the heading reads "N of M", so a narrowed table is never mistaken for a shrinking cluster. And a filter that matches nothing says so — instead of showing the "install the sensor to collect node metrics" empty state, which would send you off to debug a perfectly healthy install.

See infrastructure metrics for what the Nodes screen collects and how.

• Settings → Groups. Create a group from a name, a criticality tier (T0–T3) and the namespaces or services it covers; edit or delete it later. The change applies to the next health read — no restart, no redeploy, no PR. The Service Health board links straight to the editor instead of naming a config key.

• Auto-grouping still works. Services no group claims keep falling into their namespace at the default tier, exactly as before, so nothing disappears while you organize.

• Groups declared in the chart keep working, and win. They render read-only, because an install that manages its groups in Git must not have them quietly overridden from a browser. The conflict is refused when you try to save it, rather than discovered at the next upgrade — and if the chart later claims a name you already authored, that group is flagged as overridden instead of silently ceasing to group anything.

• Alerting and the board cannot disagree. The two sources are merged in one place shared by the health API and the alert evaluator. That matters because the evaluator does not read the API: merging anywhere else would have meant a group you created showing as critical on the board while nothing ever paged on it. A test drives both paths and then fires a real rule on a group that exists only in the database.

• Safe by construction. Writes are admin-only and validated against the same rules the chart config is checked with at startup, so nothing you can save here will fail the hub's next boot. Everyone else can read the definitions — seeing how the estate is organized is not a privilege.

Thresholds, critical edges and the default tier stay in serviceGroups for now; groups are the part people need daily.

Storage​

• The connection, read-only. Address, database and user for the ClickHouse this hub is talking to. Read-only is the honest answer rather than a missing feature: ClickHouse is the store, so it cannot hold its own connection string. The card says so and gives you the --set line, instead of a form that would quietly fail. It is shown even while ClickHouse is unreachable, which is when "which address did we fail to reach?" is the first question.

• Per-signal usage, moved here from Status: size on disk, compression ratio, row count, how far back the data goes. Each tab now answers one question — Status is is it healthy right now, Storage is what is in it.

• Retention you can trust. The days in your values are what the install is configured to keep. The TTL on the tables is what ClickHouse is enforcing — and changing a retention value does nothing to tables that already exist until the migration re-applies it. Until then the configured number is a wish. When the two disagree the column says 30d → 7d rather than repeating the wish, and a database whose retention has not been applied yet reads → none.

Access​

Which role may read, and which may change, each area of the product — service map, traces, error tracking, alerting, users, and the rest.

Every cell comes from the hub, which derives it from the authorization its routes are actually registered with. Nothing is transcribed into the browser: add an admin-only endpoint anywhere and it appears here; change what a route requires and this changes with it. A permissions table that can disagree with what the server enforces is worse than none at all, because it gets believed.

An install running without authentication says so at the top of the tab, instead of presenting a model that nothing is enforcing.

One thing this found​

Building the matrix meant indexing every route's guard — which is how we noticed that three of them had none. See the security note: if you run the green module with authentication enabled, it is worth two minutes of your time.

• Users, managed end to end. Settings → Users now edits a user's name and role grants, resets a password, and deletes a user — an explicit second step, available only after disabling, so removal is never a single misclick. A new Settings → Account tab lets any signed-in local user rotate their own password: the current password is required, other sessions are evicted, and the one you are using stays alive. Password operations are refused for SSO users, whose credential lives at the identity provider.

• An admin could mint a working local password for an SSO-only account. PUT /api/v1/users/{id} accepted a password for any user regardless of origin, and the login path never filtered on origin either — so the new credential was a real, working login that walked around the identity provider along with its MFA and conditional-access policy. Password edits are now allow-listed on local accounts, on both the admin route and the new self-service one.

• Rotating IP addresses walked straight past the login lockout. Both rate-limit axes keyed on the client address, so guesses spread across N addresses bought N × 5 attempts per minute against one account and tripped neither — any cloud NAT pool was enough to make the per-account lockout decorative. A third axis now counts failures against the account itself (20 per minute), for password login and self-service change alike. It is a deliberate trade: sustained failures will keep that account's login blocked for a self-healing one-minute window, never touching established sessions or successful logins.

• An SSO login could take over a local account's email. An identity-provider user whose email matched a local account added a second row sharing that address, and the password lookup then resolved to an arbitrary one of the two — so anyone able to set their own email claim could aim it at the bootstrap admin. The lookup is now local-first, and password login is allow-listed on local accounts rather than trusting SSO rows to carry an empty password hash.

• An install whose schema migration never ran now repairs itself. Schema is applied by a Helm post-install/post-upgrade hook — and Helm runs those only after --wait succeeds, so a release that timed out on any slow component never created the job, while the deployments Helm had already applied rolled out normally. The result looked healthy and answered unknown table to everything. The hub now checks its schema on connect and applies what is missing itself (hub.autoMigrate, on by default; the migrations are idempotent). When it cannot — no DDL rights, or self-heal switched off — it logs one error naming the remedy instead of a warning flood, and Settings → Status gains a Schema component showing applied versus expected.

• A non-default ClickHouse database name no longer breaks the install silently. clickhouse.external.database is documented and schema-checked, but every migration hardcoded the otel prefix: the tables landed in one database while the hub queried another and found it empty. Migrations now name their database through a placeholder, and the configured name is validated as an identifier at boot. Installs on the default are unaffected.

• Green no longer takes the sensor down on nodes without RAPL. The measured power source exits at startup when it finds no powercap zones, and a container that terminates itself keeps the whole pod out of Ready — so enabling green collection on a fleet of VMs took logs, traces and metrics down with an optional energy signal. The measured source can now be dropped on its own with sensor.green.kepler.enabled=false, leaving TDP estimation to feed the Green page. RAPL hardware is unaffected.

• Logging in through a reverse proxy that rewrites Host no longer 403s. The CSRF check compared the browser's Origin against the Host the hub received, so a proxy handing the cluster its ingress address turned every write — the login POST first of all — into a rejected cross-origin request. auth.trustedOrigins names the origins that are legitimate despite not matching Host, and auth.originCheck (enforce | log | off) lowers the check when they cannot be enumerated; log allows the write and records the Origin/Host pair, which is how you find out what your proxy actually sends. The default stays strict, and an OIDC publicUrl is trusted automatically.

Upgrading from v0.3.x is a normal helm upgrade. Schema migration 0015 applies automatically. If you run a hardened ClickHouse user without DDL rights, keep the migrate job as-is and leave hub.autoMigrate on — it will report cleanly rather than fail. See the Releases page and the GitHub release.

• Projects you administer. Create, rename and delete projects in Settings → General; the switcher and the General tab follow immediately, while the built-in default and any project declared in the chart stay read-only and clearly labelled. A project's id is an immutable tenant slug — only its display name is editable, so no telemetry is ever rewritten or lost.
• Telemetry that proves whose it is. Mint per-project ingest API keys; the raw secret is shown exactly once and only its hash is stored. Keys are validated in the gateway — the hub never enters the telemetry byte-path — and in enforce mode the key's project becomes the authoritative tenant: a sender that lies about its tenant lands where its key says. The default log mode leaves the pipeline byte-identical, so the drop-in OTLP promise survives the upgrade.
• A demo you can hand to anyone. One click on the login page signs a visitor in as a read-only viewer scoped to a single project; the shared password stays server-side and never reaches the browser. Pair it with the astronomy-shop overlay for live data across every module.
• Green on cloud VMs. Public-cloud instances expose no power counters, so an opt-in power model now fills the gap — every modeled number labeled estimated end to end, never blended with measured energy, with a new coverage panel that makes the RAPL-less share of a fleet visible (details).
• Runtime collection control — groundwork. The hub can now store and serve a bounded, schema-validated collection overlay behind a default-off flag and a least-privilege Role. The applier and the editable UI come next; collection is still configured through Helm values today.
• Breaking: avuruops is now avuruobs. The Helm chart, the AVURUOBS_* environment variables, the mount paths and the generated resource names all match the project's name now. Upgrading from 0.2.x is not a plain helm upgrade — follow the upgrade guide, which gives you a no-rename path (--set nameOverride=avuruops) and a clean-install path.

Also fixed: a fresh install with the demo enabled could end up with no admin account (the demo viewer satisfied the bootstrap guard, so admin was never created and every sign-in failed as if the password were wrong) — affected installs repair themselves on the next restart. Plus a first-install Helm render failure, the demo visitor landing on the wrong project, and login behind a reverse proxy on a non-default port.

See the full notes on the Releases page and the GitHub release. The trunk is now 0.4.0-SNAPSHOT — next up on the Roadmap: multi-cluster member projects, the collection control plane finished end to end, and wider ingest compatibility.

• Both halves of the reference were wrong. The repositories named Docker Hub coordinates that nothing publishes, while releases push to ghcr.io/avuruvision/avuru-obs-<component>; and the tag defaulted to the chart's appVersion — bare SemVer, no leading v — while only vX.Y.Z and vX.Y were ever pushed. Fixing one without the other would only have swapped one unresolvable reference for another, so both are fixed: the four first-party repositories point at the registry, and the release workflow now also publishes the bare X.Y.Z tag.
• Green TDP estimation had no image at all. Its repository shipped empty, so enabling the estimator rendered a reference with no name and no tag. It now defaults like the other three first-party images.

If you are on v0.3.0, helm upgrade to 0.3.1 and you can drop any --set hub.repository=… / --set …tag=… you added to work around this. Installs that pin images deliberately — a private registry through image.registry, or air-gapped mirrors — are unaffected either way.

See the Releases page and the GitHub release.

• Honest by construction. Every number the estimator produces is stamped estimated through the whole chain — the SQL, the API, the UI and the CSRD export's methodology block — and is never blended with RAPL-measured energy. Estimated and measured energy for the same service appear as separate rows, so a total can never quietly mix the two. Treat estimates as trend and regression grade (±30-50% typical error), not audit grade.
• The RAPL-less share becomes visible. /green gains a coverage panel breaking the fleet into known, measured, estimated and absent nodes. What used to be silently missing is now something you can see and act on.
• Budgets account for it. Carbon budgets include estimated energy, so an all-VM fleet's budget can actually trip — and a breach states how much of it is modeled versus measured.
• Sourced coefficients. The bundled CPU power table is cited (Cloud Carbon Footprint, cross-checked against the SPECpower-derived source notebook), and operators can override P_idle/P_max per node or fleet-wide.

Enable it with sensor.green.estimation.enabled (it requires sensor.green.enabled — the estimator is a fallback for the same energy signal, not a second source). See the green module docs.

• The key decides the project. Mint keys in Settings → General → Ingest API keys (or POST /api/v1/projects/{project}/keys). In enforce mode the validated key's project becomes the authoritative tenant, overriding any value the sender supplied. A misconfigured — or dishonest — sender can no longer write into a project it was never granted.
• The secret is shown exactly once. Only a SHA-256 hash is stored, so the raw key cannot be recovered from the database or the API. The list view shows a short prefix and metadata for identification; revoking is immediate.
• Your ingest path stays fast. Keys are validated in the gateway, by a purpose-built collector extension. The hub answers a control-plane question and is never in the telemetry byte-path. Verdicts are cached, and a cached verdict keeps serving through a hub restart — a control-plane blip cannot drop your traffic.
• A three-stage rollout, not a switch. auth.ingest.mode moves through off → log → enforce. log is the default: keys are validated and would-be denials counted, but nothing is rejected and the pipeline is byte-identical to before. That gives you a precise list of senders that would break before they do. Flip to enforce once it reads zero.
• Existing senders keep working. Upgrading changes nothing on its own — the drop-in promise holds. The chart also provisions and seeds a key for the node sensor automatically, so turning on enforce never silences your own agent.

• Create, rename, delete — from the app. An admin-only project card on Settings → General adds new projects, edits a project's display name, and deletes UI-managed ones. The sidebar switcher and General tab reflect changes immediately. Non-admins keep read-only visibility of the projects they're granted.
• Deployment-owned projects stay protected. The built-in default project and any project declared in the chart (projects value / AVURUOBS_PROJECTS) are clearly marked and cannot be edited or deleted from the UI — the app refuses with a 409, so your source-of-truth config always wins.
• A stable id, an editable name. A project's id is an immutable tenant slug — the partition key on every trace, log and metric; only its display label is editable. Renaming or deleting never rewrites telemetry: a delete removes the entry and its data ages out by the existing retention, and a still-active tenant simply reappears as auto-discovered.
• Admin-enforced, server-side. The new POST / PUT / DELETE /api/v1/projects endpoints require a global admin (403 otherwise), and GET /api/v1/projects now returns each project's source, label and editable flag. See the API reference.
• Groundwork for what's next. This is the first slice of the projects work; per-project ingest keys and multi-cluster aggregate views build on the same model.

• One click, zero setup. A "Try the demo" button on the login page signs a visitor straight in as a read-only viewer scoped to a demo project — no account to create, nothing to install. The rest of the app behaves exactly as it would for a real user; write actions (triage, settings, user admin) simply aren't offered.
• Real data, every module. The demo is fed by the live OpenTelemetry Astronomy Shop — a genuine multi-service application — so the service map, traces, logs, RED metrics, error tracking, service health and energy views all show real, moving data instead of static screenshots.
• Safe by construction. The demo is a single low-privilege identity: the shared password stays server-side (a rate-limited sign-in endpoint), never reaching the browser, and the whole feature is opt-in — a normal install ships no demo user and no demo project. Enable it with auth.demo.enabled.
• Also in this release. The Settings Users tab now opens in place instead of navigating away, so the tab bar no longer disappears; the login wordmark reads Avuru Obs. See the API reference for the new demo sign-in endpoint.

• Secure by default. New installs require login (auth.enabled=true); Helm bootstraps an admin user whose password lives in the release Secret. Every API route is enforced server-side, and the project header is validated against the caller's grants — projects become a real security boundary: a user granted only staging gets 403 anywhere else and a project switcher that lists only staging. auth.enabled=false restores the previous open behavior. See Security.
• Roles × projects, not an ACL maze. Three fixed roles — Admin, Editor, Viewer — granted per project (or * for all). A login page and a Settings → Users admin screen come with it; the endpoint surface is in the API reference.
• Sign in with your company IdP. The hub runs the OIDC authorization-code + PKCE flow itself (/api/v1/auth/oidc/start → IdP → /api/v1/auth/oidc/callback) — no extra pod, no proxy in front. Provider discovery is fail-loud at startup, so a wrong issuer stops the rollout instead of shipping a broken login, and an SSO login ends in the same server-side session as a local one.
• Group-based access, zero per-user admin. auth.oidc.mapping maps IdP groups to a role on projects declaratively (with a defaultRole fallback). Groups are refreshed at each SSO sign-in and the mapping is applied on every request from the hot-reloaded config file (~15 s, no restart) — an access policy change takes effect without touching individual accounts.
• forceSSO for centralized policy. Hides the local password form so the IdP is the only door for people — the local admin API login stays available as break-glass. Everything is configured from Helm values (auth.oidc.*); the client secret comes from your own Secret or a chart-managed one, never the config file.
• Sessions you can actually revoke. Sessions are server-side (revocation is immediate), logins are rate-limited, and state lives in the existing database — no new components.
• Opt-in anonymous viewing. Grant visitors a role on an explicit project list only: a public demo can share one project while every other project stays invisible.

• A licensing page you can actually read. A new License & sustainability page (EN + FR) answers the questions people actually have: self-hosting is zero-obligation, observing your services never makes them derivative works, and the AGPL only asks something of you if you modify avuru obs itself and offer it to third parties over a network.
• Nothing is gated. Authentication, roles, per-project access control and OIDC SSO — capabilities frequently reserved for paid tiers elsewhere — are in the open edition. AGPL-3.0, forever.
• Every contribution stays open. The Contributor License Agreement §2.2 legally pledges that every contribution remains available under AGPL-3.0 — the open edition can never be closed or stripped down retroactively.
• The sensor stays Apache-2.0. The eBPF node agent is upstream OpenTelemetry eBPF Instrumentation (OBI), configured — not forked — so it keeps its permissive license.
• Third-party attribution, generated not hand-kept. A make notices target produces THIRD-PARTY-NOTICES.md from the actual Go and TypeScript dependency trees, wired into the release checklist so attribution never drifts from what ships.
• Why the AGPL, said out loud. An observability platform holds the most sensitive telemetry an organization produces. avuru obs is built as a sovereign alternative to per-host SaaS billing — and the AGPL is what keeps the open edition from being enclosed into someone else's closed service.

• Secure by default. The hub now requires login: local users with Admin, Editor and Viewer roles granted per project, enforced server-side on every API route — projects become a real security boundary, not a filter. Add enterprise SSO with any OpenID Connect IdP (group→role mapping, forceSSO for IdP-only fleets) — no proxy sidecar, no extra pod (security guide).
• Pick your signals. One switch per signal family (modules.<name>.enabled) gates its schema, API, pipeline, collection and UI together — a traces-only install carries no log or profile weight, and the sidebar follows what the install advertises.
• Error tracking. Exceptions already in your spans and logs become deduplicated, triageable issues — stack trace, occurrence timeline, link to the originating trace, resolved/ignored lifecycle with regression detection. Browser apps report too, by changing one DSN — the signal eBPF cannot reach.
• Service health & alerting. Group services with criticality tiers (T0/T1/T2) and dependency propagation — a service can't read green while a critical dependency is red — then get a webhook (SSRF-guarded, with firing/resolved lifecycle) when a group crosses into a bad state.
• Network health on the map. Per-edge RTT and failed/reset connection counts from eBPF TCP stats — connection-level health without traces or SDKs.
• Green: energy & carbon. Per-service Wh and gCO2e measured at the node (opt-in, RAPL hardware), monthly carbon budgets with alerts, and a CSRD-ready export that states its methodology. Nothing leaves the cluster.
• A sensor that is provably safe to leave on. CI keeps a probe-sensitive canary healthy through a soak with the sensor attached; cautious fleets get an opt-in discovery mode and a staged-rollout runbook.
• AGPL-3.0. The project is now licensed AGPL-3.0.

See the full notes on the Releases page and the GitHub release. The trunk is now 0.3.0-SNAPSHOT — next up on the Roadmap: per-project ingest keys, the runtime collection control plane, and wider ingest compatibility.

• Numbers an auditor can reproduce. A CSRD-ready CSV/JSON export carries a methodology block — the formula, the grid-intensity factor and its provenance, the measurement coverage ratio, and an explicit unattributed bucket — so a reported gCO2e is traceable back to how it was produced.
• Carbon budgets per team. Monthly gCO2e budgets per service group, with warn at 80%, exceeded at 100%, and a month-end projection — delivered through the alerting channels you already configured. With alerting off, budgets still show status on the dashboard.
• Efficiency you can prove. Per-request carbon intensity (Wh ÷ requests, gCO2e derived) and a per-service trend, so an optimization shows up even as traffic grows — plus a gCO2e overlay on the service map you already watch.
• Offline by design. Grid-intensity factors are bundled per-country annual averages with operator overrides in config; gCO2e = Wh × intensity × PUE runs in the hub at query time. No egress, air-gap friendly.
• No new storage, no code changes. All math runs over the metric tables that already exist — no migration. Kepler joins the sensor as an opt-in, probe-free container (sensor.green.enabled), so it can never destabilize the sensor pod, and on nodes without RAPL the module reports honestly (a coverage ratio and a teaching empty state) rather than estimating.
• Off by default. The signal depends on RAPL/powercap hardware, so modules.green.enabled ships off — an existing install upgrades unchanged. It requires the infra-metrics module for the pod→workload join.

:::caution Confirm on real hardware before production Kepler's metric names, config keys and port are validated in CI against the pinned image's dev meter, but must be confirmed on real RAPL hardware before production use. The hub's metric names are configurable for exactly this reason. See the Green page. :::