Adding a Provider
Every provider follows the same shape, defined by the ProviderAdapter contract in
src/collectors/types.ts: a collect(context) function that returns a uniform result —
resources, metrics, costs, healthChecks, errors, and a status
(success | partial_success | skipped | failed).
The dependency-injection seam
Section titled “The dependency-injection seam”Adapters never construct their own network clients — they receive a client interface, and the real
implementation lives separately in liveClients/. Tests inject fakes; nothing in providers/
makes a real network call. Keep that split when adding a new provider.
Use an existing adapter (e.g. src/collectors/providers/cloudflare.ts) as a reference.
- Extend
ProviderKeyinsrc/types.tswith your provider’s key. - Add
src/collectors/providers/<name>.ts— pure adapter logic. It takes a typed client interface and maps the response into theCollectorAdapterResultshape. Nofetch, no SDK client construction, no env var reads here. - Add
src/collectors/liveClients/<name>.ts— the real implementation of that client interface (actual API/SDK calls, given credentials as plain arguments). - Wire it into
src/collectors/runConfiguredCollectors.tsbehind a credential check — the adapter is only added to the run when its required env vars/config fields are present. This file is the one place that reads env vars and config. - Add a label and icon in
providerLabels/ the icon map insrc/App.tsxso the frontend renders your provider nicely. - Add a mocked test under
src/tests/collectors/providers/<name>.test.tscovering at least success, partial/degraded, and error cases with a fake client — no real network calls in CI. - Document credentials in the config table and required-secrets list in
docs/SELF_HOSTING.md, and add the env var(s) to.env.example.
Data boundaries
Section titled “Data boundaries”See the architecture page for the full data-safety rules.