Why We Built Ampbase

Ampbase is an OpAMP control plane for the agents running on your hosts — Fluent Bit, Vector, Telegraf, OTel Collector, coding agents, and Tetragon — managed from one place with versioned configs and flag-driven rollouts. There's a 14-day trial and SSO on every plan.

Count the long-running agents on the machines you operate. There’s a log shipper. Probably Fluent Bit, the small C daemon that tails your logs and forwards them on, and one of the most widely deployed programs on the internet. Maybe an OTel Collector beside it. Since last year, Claude Code or Cursor on every developer’s laptop. Maybe an eBPF security agent on the servers, put there by a different team, whose config you have never seen.

Now ask which of them you could reconfigure on ten percent of machines this afternoon, and put back in one action when it goes wrong.

You manage your application deploys. You have a rollout strategy, a canary, a rollback button, and a dashboard that tells you which version is running where. Then there’s the agent shipping the logs that make all of that observable (a DaemonSet on every node, a systemd unit on every VM, a sidecar wherever somebody needed per-app isolation), and its config is a ConfigMap, or a template in a Chef cookbook, that somebody edited fourteen months ago. You don’t know what version of the config it’s running. You can’t change it on a subset of hosts. If you break it, you find out when the logs stop.

That’s the gap. Ampbase closes it by giving agent config what your application deploys have had for a decade: a canary you can widen, a rollback that’s one click and no deploy. And one thing your deploys never gave you: the agent telling you what it actually loaded.

Which changes the cadence, not just the risk. When a change can be canaried and undone in one action you stop saving them up for a window, and start adjusting telemetry on a Tuesday because a service got noisy, then again on Friday afternoon. That’s a sentence nobody currently says out loud. That fourteen-month-old ConfigMap isn’t neglect. It’s what all-or-nothing does to a cadence.

The config is on the wrong side of the deploy #

This isn’t a discipline problem and nobody chose it. It follows from where the config lives.

Agent configuration lives on disk. Fluent Bit reads fluent-bit.conf, Vector reads vector.toml, the OTel Collector reads config.yaml, every one designed around the assumption that a file lands on a filesystem and the process reads it at startup. So it gets delivered by whatever puts files on filesystems in your shop: Ansible, Chef, Puppet, a Helm chart, a baked AMI, a Dockerfile COPY. The unit of change for your agent config is a deploy of your configuration management system, and that has consequences you didn’t choose:

Blast radius is whatever your CM tool’s blast radius is. Ansible runs against an inventory. Helm upgrades a release. Neither of those is “10% of agents, weighted, stable across restarts.” You get all of them, or whatever arbitrary slice your inventory groups happen to carve out. Most teams get all of them.

Rollback is another deploy. You changed a Vector transform, cardinality exploded, your metrics bill is now a problem. Revert the commit, wait for CI, run the playbook, wait for convergence, somewhere between four minutes and forty depending on the shop. The whole time, you’re paying.

Nobody knows what’s actually running. Your CM tool knows what it last tried to apply. It does not know which agents parsed the new config and which quietly fell back to the old one, so the loop from “applied” to “working” gets closed by a human noticing a gap in a graph.

And it compounds once per agent type. Almost nobody runs one. Fluent Bit on the legacy fleet, an OTel Collector for the new services, Telegraf because the database team likes it. Then the coding agents arrived on the laptops and a runtime security agent landed on the servers. Each has its own config format, its own reload semantics, its own idea of a valid file, so each gets its own delivery path and its own way of going wrong. You are not maintaining a config pipeline. You are maintaining one per agent type, and none of them can see each other.

None of this is a new observation. This is usually the point where somebody says: just do GitOps.

“Just do GitOps” #

Put the configs in a repo, point Flux or Argo at it, let the reconciler converge. We hear this a lot, and we’ve done this a lot. It’s a reasonable instinct, it’s how the rest of your infrastructure already works, and for a hundred agents it is completely fine. But it’s never felt just right. At fleet scale it adds two problems to the ones above.

Git can’t express a rollout. “Ten percent of agents, and the same ten percent after a restart” is not a file. It’s a function over agent identity. To get it into Git you have to materialize it into a manifest that goes stale the instant an autoscaler adds a node. What you want to version is the policy. What Git makes you version is the policy’s output, evaluated once, by hand, at commit time.

Review is the wrong instrument for the failure that costs you. A pull request catches a typo in a regex. It does not tell you the label you just added has four million distinct values and is about to triple your metrics bill. Only the data has seen the cardinality, and the data is not in the pull request.

And the missing feedback loop gets worse here, because of what these particular agents are. For most workloads, desired-state-in-hope-out is survivable, because something outside the workload is watching. That something is your telemetry agents. Ship their config through the same pipeline as everything else and a bad agent config takes out your ability to see that the agent config is bad. The failure conceals itself: the dashboards don’t go red, they go quiet, and quiet reads exactly like healthy until somebody asks why there are no logs from Tuesday. Every other GitOps workload can be observed by something standing outside it. This one is the thing standing outside.

None of which makes GitOps wrong, and you don’t give up what it gave you: every config version in Ampbase is immutable, ULID-keyed, and append-only, so the who-changed-what-when survives intact.

Then there’s the near cousin of that suggestion, and it’s the better one: don’t switch tools, just make the one you have better. Templated configs, richer inventory groups, a canary playbook somebody owns. It’s the right instinct, and it walks straight into everything above: you’d build an evaluation engine for the bucketing, a protocol and a client for the reporting back, then both again for the next agent type. That isn’t a cheaper version of this product. It’s the same one, assembled on your time.

So the config has to come out of the deploy pipeline, and something has to report back what actually took. There’s a protocol for both.

OpAMP closes the loop #

OpAMP, the Open Agent Management Protocol, is an OpenTelemetry specification for a bidirectional connection between an agent and a control plane. It’s still pretty new, with an active community, which is important for something you’re putting at the core of a product. The agent connects and reports what it is. The server pushes a remote config down the same connection. The agent applies it and reports back the effective config: what it’s actually running, not what it was told to run, plus health and whether the last apply succeeded.

That last part is the one people skip past. Config delivery is the easy part; a cron job and a signed URL would do. What matters is the agent telling you what it ended up with. The feedback loop that didn’t exist now exists, in the protocol, by default.

There’s one catch, and it decides how far any of this reaches: almost nothing speaks OpAMP natively. Fluent Bit doesn’t. Neither does Claude Code. So a small supervisor process sits beside each agent and speaks it on the agent’s behalf: takes the config down, writes it where that agent expects to find it, signals the process, watches what happens, and reports back what actually loaded. That’s the piece that decides whether OpAMP is a protocol for new agents or a control plane for the ones you already run. We’ve got a lot more to say about it in a future post. What matters here is that the same route reaches a decade-old log shipper and a coding agent released last month.

Once an agent can receive config over a connection and report the result, config stops being a filesystem artifact and becomes a runtime decision. And a runtime decision is something you can route.

What already existed, and why we wrote another one #

We weren’t first. BindPlane is the most mature OpAMP control plane out there and it’s good, but it’s built around the OTel Collector, so if your fleet is 60% Fluent Bit you’re managing the minority of your agents and doing the rest by hand. Grafana Fleet Management solves it inside the Grafana stack, which is the obvious answer if you’re all in on Grafana and no answer at all if you ship to three backends because different teams chose differently in different years.

So the gap wasn’t “nobody has built this.” Every existing implementation is anchored to one agent or one backend, and the fleets that hurt most are anchored to neither. Vendor neutrality sounds like a marketing bullet. Here it’s a description of the technical problem: several kinds of agent, no single tool that speaks to all of them.

That’s the boring reason we built it. Here’s the interesting one.

A config rollout is a feature flag #

OpAMP is the half that makes this possible. This is the half that makes it worth having, and it’s the part I’d still find worth reading if a competitor had written it.

Think about what you actually want when you change an agent config. Not “push this file everywhere.” You want:

• this new version, on 5% of agents, to start
• specifically including the three hosts in us-east-1 you’re using to validate
• excluding anything tagged env=prod until it’s proven
• with the assignment stable, so an agent that restarts doesn’t flip to a different config and reset your sample
• and reversible in one action, without a deploy

Read that list again with no context about observability. It’s a feature flag. Every single requirement on it is a feature flag requirement: percentage rollout, targeting rules over attributes, deterministic bucketing, instant kill switch.

Feature flagging is a solved problem. It has a CNCF specification, OpenFeature, and a reference implementation, flagd, that is unglamorous and works. So rather than invent a rollout engine and spend three years rediscovering the edge cases flag vendors already found, we built the rollout layer on flag evaluation.

It’s there when you need it and stays out of the way when you don’t. Deploy a version and every connected agent picks it up on its next OpAMP message: no flag, no targeting, no ceremony. The flag is what you reach for when all-at-once stops being acceptable. The agent presents its attributes as an evaluation context, and every requirement on that list stops being something you build and becomes something you configure.

The architecture that falls out of it #

Three consequences worth naming, because they’re the parts people usually argue with. Each gets a post of its own.

One app per customer. Its own control plane instance, its own bucket, its own analytics partition. More to operate than a row in a tenants table, in exchange for a cross-tenant leak needing a failure of the infrastructure boundary rather than a bug in a WHERE clause. Ask us again in a year.

Object storage is the database.* No Postgres, no Redis, no Kafka, no failover to rehearse once a year and still fumble at three in the morning. We’ve run databases of every shape and size, self-hosted and managed, and as good as they all are, none of them ask as little of us as a bucket does. Deploying is a pointer move, which is also why rolling back is one. The asterisk is ClickHouse, and we’d rather own it out loud than write the paragraph where a ListObjectsV2 loop gets described as a query engine.

The supervisor is Rust, because it lands on every machine in your fleet, where its footprint is a tax on everything you monitor and where it must never, under any circumstance, be the reason the logs stopped.

And one that isn’t architecture at all, but an invoice: telling you which labels are wrecking your bill means knowing what you’re sending, which sounds like it requires ingesting your telemetry raw, and doesn’t. The reduction happens on your host, so what crosses the wire is sketch state and counts while every value stays where it was, which produces a sentence we’ve grown fond of, and a post to go with it. We can tell you a label has four million distinct values without ever having seen one of them.

Then everybody’s laptop became a fleet #

Here’s the part we didn’t plan. Partway through building this, Claude Code and Codex CLI and Cursor stopped being curiosities and became standard tooling, and security teams started asking the obvious questions. Which leaves you with a few thousand processes on machines nobody is sitting at, each with a configuration that has to be set centrally and verified constantly. We had seen this before. It’s Fluent Bit with the nouns changed.

We didn’t build a second product for it. Coding agents became another agent type: same supervisor, same OpAMP connection, same versioned and flag-routed config. That’s the strongest evidence we have that the shape is right, and it isn’t evidence we manufactured: a design that fits only the workload it was designed for hasn’t really been tested.

Somewhere in there the word “agent” started meaning two things, and we’ve elected to enjoy that rather than fight it: the OG kind ships your logs, your new team of agents ships your code, and both are long-running processes whose config deserves a real rollout. That was the thesis all along.

What this doesn’t do #

Some things we’ve decided not to be, so nobody has to discover them the annoying way.

Ampbase is not an observability backend. It doesn’t store your logs or metrics. It manages your fleet: the agents shipping telemetry wherever you’re shipping it, the coding agents on your developers’ machines, and the runtime security agents on your servers.

It’s not an agent-orchestration platform, either, in the other meaning of the word. We don’t run AI agents, schedule them, or host their compute. We manage the configuration of the ones you already run, the same way we manage your collectors'.

It doesn’t write your configs for you. There’s no drag-and-drop pipeline builder. You author agent config in the format the agent already uses, because translating it into someone’s proprietary abstraction is how you end up unable to leave. (Let’s be honest: your coding agents are writing your telemetry configs now anyway.)

And it isn’t for everyone yet. One agent type on thirty machines, one config you templated once and haven’t touched since? You need a text editor and a deploy, not this. The model starts earning its keep when the fleet is large enough that a single config change is frightening, or when you’re running more than one kind of agent and quietly maintaining a delivery path for each. Plenty of people cross that second line without noticing, usually the week the coding agents arrive.

It isn’t a replacement for your CM tool, either. Something still has to install the supervisor. What changes is that installation happens once, and the config it manages afterward is no longer coupled to your deploy pipeline.

Where this is #

We’re taking the gate off production. There’s a trial, the paid tiers are priced by agent count, and SSO is on every one of them, including the cheapest, because charging extra for the login integration that lets a company adopt you safely is a tax on the wrong thing.

If you run a fleet with more than one agent type in it, or a few thousand laptops with a coding agent on each of them, we’d like to hear where this model breaks for you. That’s a genuinely open question and the answer is worth more to us right now than a signup.