How Ampbase works

Ampbase is an OpAMP control plane: a single place to push configs, route rollouts, and watch the health of every agent in your fleet — telemetry collectors, AI coding agents, and eBPF security agents alike. Before you start wiring it up, the mental model is worth five minutes.

Three nouns

Organization → Channel → Agent

• Organization — your company's account. Billing, members, and SSO scope here. Each org has a slug (e.g. acme) that becomes part of every OpAMP endpoint URL.
• Channel — a grouping of agents that share one deployed config and one rollout lifecycle. Model a channel per role (the job an agent does and where its telemetry goes, e.g. clickhouse, vault) — not per environment. Environment, region, and canary are agent attributes you route with flags, not channels. See Structuring your channels for the full reasoning. Channels also have slugs.
• Agent — anything that speaks OpAMP and presents a valid agent key. In practice that's the Ampbase supervisor managing OpenTelemetry Collector, Fluent Bit, Vector, Telegraf or Refinery; the AI coding-agent runtimes on a developer workstation; or Tetragon on a Linux host. See Agents for all three classes.

Why "channel"? It's borrowed from a mixing desk, where a channel is one input strip — configured and routed on its own. That independence is the point of the word, and it's the reason for the rule above: a strip doesn't describe where its signal ends up, so environment, region, and canary ride on agents rather than in channel names.

Every agent connects to exactly one channel. The endpoint is built from the two slugs:

wss://{org_slug}.ampbase.io/channels/{channel_slug}/v1/opamp

What gets pushed

Inside a channel, you author configurations — the YAML or TOML your agent normally reads from disk. Ampbase versions every save (ULID-keyed, append-only), so nothing is ever overwritten. Deploying a version makes it the one agents receive on their next OpAMP message.

Bundles let you compose multiple configurations into one deployable unit — useful when an agent reads more than one file (Refinery's config plus its rules) or when you want to share a base config across many deployments and layer additions on top. A bundle is scoped to one agent type.

How rollouts decide

Between "I authored a new version" and "every agent picks it up" sits a feature flag. A flag answers the question "which version does this agent get?" — and that answer can be conditional.

   you author a config
        │   every save is a new version — nothing is overwritten
        ▼
   v1 ─▶ v2 ─▶ v3 ─▶ v4
               │
               │   you deploy v3 — the channel's default
               ▼
   an agent connects, presenting its key and its
   attributes (region, env, anything you set)
        │
        ▼
   does a flag rule match this agent?
        │
        ├─ no  ─▶  it gets the deployed config    (v3)
        └─ yes ─▶  it gets the variant's target   (v4)

The deployed config is the answer for everyone unless a flag says otherwise — which is why picking it is the whole of the channel modeling question. A matched variant also has to be runnable by the agent's build; where it isn't, that agent falls back to the deployed config too. See Feature flags, under Build eligibility.

• Simple routing: one variant at 100%. Everyone gets v3.
• Weighted rollout: 90% to v3, 10% to v4. Deterministic per-agent bucketing keeps the assignment stable across reconnects.
• Targeting: rules over agent attributes (region, env, anything you set in supervisor.yaml). Canary your us-east-1 fleet before flipping global.

Flag definitions sync to each channel every few seconds and evaluate in-process — no extra round trip in the agent connection path.

Data isolation

Every organization gets its own object-storage bucket and its own database partition. Cross-tenant operations are avoided by design. SSO, audit log, and webhook delivery work the same on every paid tier — no enterprise tax.

Where to go next

• Structuring your channels — how to decide what belongs in a channel.
• Agents — connection lifecycle and agent keys.
• Configurations — versioning, deploys, and bundles.
• Feature flags — variants, weights, and targeting.
• Your first config — walk through it end-to-end.