# OTelBin, a web editor for OpenTelemetry Collector configurations > OTelBin is a browser tool that draws your OpenTelemetry Collector configuration as swimlanes, validates it, and gives you a shareable link and a documentation badge. The validation is the interesting part, because it runs the configuration against a real collector through a separate validation service. **dash0hq/otelbin** — Web-based tool to facilitate OpenTelemetry collector configuration editing and verification - Repository: https://github.com/dash0hq/otelbin - Website: https://www.otelbin.io - Stars: 584 · Forks: 31 - Language: TypeScript - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/dash0hq-otelbin ## Collector configuration is a graph, and YAML hides that OTelBin is described as a configuration tool to help you get the most out of the OpenTelemetry Collector, and the project summary calls it a configuration tool for OpenTelemetry collector pipelines. It is hosted by the Dash0 people at otelbin.io. The problem it solves is a legibility one. A Collector configuration is a set of receivers, processors and exporters, and in YAML that set is a flat list of sections with a tangled set of pipeline definitions referring to each other. You can read it, but you cannot see it. The pipeline is a directed graph of components, and a graph is exactly what a person cannot hold in their head from a YAML listing. So the tool does three things, and the feature list states them plainly. It visualizes the configured OpenTelemetry Collector pipelines as swimlanes, it validates your configuration and highlights errors, and it enables you to share your OpenTelemetry Collector configurations online, which requires login with a GitHub or Google account. The three map onto three different moments in a workflow. Visualisation is for the moment you have just written a configuration and want to know whether it is what you meant. Validation is for the moment before you deploy it. Sharing is for the moment you want someone else, or a README, to see the pipeline you built. The audience is an engineer working with the Collector, which in practice means someone on an observability team or a platform team. The tool is not a Collector, it does not receive telemetry, and it does not replace the Collector. It is a companion for the configuration file. The licence is Apache-2.0, the last push to the repository was on 2026-10-17, and there are no GitHub releases recorded, so the project is consumed as a hosted service or from source. ## Swimlanes for receivers, processors and exporters The visualisation choice of swimlanes is the right one for a Collector configuration, and it is worth understanding why. A Collector pipeline is conventionally described in terms of pipeline kinds: a traces pipeline, a metrics pipeline, a logs pipeline. Each kind names the receivers that feed it, the processors it runs through, and the exporters it sends to. Those are exactly the columns of a swimlane diagram. Each pipeline is a lane, and within a lane the components appear in the order the data flows through them. So the visualisation answers the question that a YAML file makes hard: what is the actual path of a span, a metric or a log through my Collector. If two exporters are attached to one receiver, you see the branch. If a processor is in the traces pipeline but not the metrics pipeline, you see the asymmetry. If you intended a fan-out to two backends and the configuration only has one, you see it immediately. The rendering is done with ReactFlow, and the front end is Next.js with TypeScript and Tailwind for styling. The hosted version runs on Vercel with privacy-friendly analytics, and Upstash provides the Redis the sharing feature uses. The authentication choice is Clerk, and the only place authentication is needed is the sharing feature, since the documentation states that sharing requires login with a GitHub or Google account. That is a sensible split: editing and validating a configuration is a local or public-page activity, and only storing a shareable copy needs an account. The badges feature is the piece that makes the tool part of a documentation workflow rather than a one-off utility. You can put a shields.io-powered badge in your docs that renders the collector configuration, in URL, Markdown or HTML form, so a README can show the pipeline without a screenshot going stale. ## Validation runs against a real collector on AWS Lambda The validation feature is the one with a real backend, and the tech stack line explains how it works: AWS Lambda is used for validation of configs against OpenTelemetry collectors. That is a meaningful architectural decision. Validating a Collector configuration statically would only catch schema errors, and the schema is not where Collector configurations usually go wrong. The classic failures are semantic: a receiver that emits a type the pipeline does not declare, a processor that expects a field the receiver never produced, an exporter configured for a protocol the collector was not built with, a service pipeline that names a component which does not exist in the build. Running the configuration against a collector instance catches that class of problem, because the collector itself will refuse to start or will report the failure. The metadata that makes this possible comes from outside the project. The acknowledgements section states that OTelBin makes use of the output of cfgmetadatagen, and specifically a post-processed version of it that is part of the nimbushq/otel-validator project. The upstream tool lives in the opentelemetry-collector-contrib repository. That dependency has a consequence worth stating plainly. The set of components and settings the validator knows about is bounded by the metadata set, which is regenerated from a specific collector-contrib state. A component that is new, or that is in the core collector rather than contrib, may not be validated correctly, and the error you get may be about a component the validator does not model rather than about your configuration. The acknowledgements are honest about the provenance, but the practical consequence is that a green validation is evidence about the components the metadata set covers. The repository layout backs up the split. There is a `packages/` directory, and the Makefile names the members: `packages/otelbin` for the application, `packages/otelbin-validation` for the validation service, and `packages/otelbin-validation-image` for the container image that carries the collector. The Makefile header says the targets are the top-level make targets across the three packages. ## Three packages, and a Makefile that documents the workflow The Makefile at the root is a good map of how this project is developed, and its help text lists the targets a contributor actually uses. ```bash @echo " make install Install deps in every package (npm ci)" @echo " make test Run tests in every package" @echo " make lint Run lint (otelbin app)" @echo " make dev Start the otelbin dev server" @echo " make build Build every package" @echo " make coverage Run the otelbin coverage report" ``` Each top-level target fans out to the three packages, and the Makefile also documents per-package targets for faster feedback, so `make test-otelbin` or `make build-validation` runs one package rather than all three. Two of the targets are worth reading closely because they describe what the validation service needs from its environment. The synth test is a CDK synth check for the validation stack, and the help text notes that it needs some /tmp headroom. The integration test is a live-AWS integration test, and the help text says it requires `API_GATEWAY_URL` and `VALIDATION_API_KEY`. So the validation service is deployed as infrastructure, with an API gateway in front of it and an API key, and the test suite includes a check that the deployed stack synthesizes and a check that talks to the real thing. That is a much heavier test posture than a unit test suite, and it tells you that the validation service is a real deployment with real cost, not a local subprocess. The `install-validation-image` target builds the image containing the collector that the validation service runs, which is the piece that makes the whole feature work. A Collector image has to be built for the component set being validated, and the combination of a per-version image and a metadata set is what makes the semantic checks possible. The repository also carries a `Makefile` helper, a `CODE_OF_CONDUCT.md`, a `CONTRIBUTING.md` and a `.nvmrc` pinning the Node version, and the top-level `packages/` layout with no application source at the root, which is a monorepo convention that keeps the three deployables cleanly separated. ## The hosted service, and the question of where your config goes There is an operational reality here that any team should think about before using the hosted version, and it is not a criticism of the project so much as a property of the design. The configuration you are editing describes your telemetry infrastructure. It names your exporters and therefore your observability vendors, and it can contain credentials, endpoint URLs and headers if you put them there. The tool's own README says it is hosted by Dash0 at otelbin.io, and the feature list says sharing a configuration online requires login with a GitHub or Google account. So the share feature, which is the feature that makes the tool pleasant, is the feature that puts your configuration somewhere you did not choose. That is a decision a security team may want to make rather than a developer, and the tool is a good candidate for self-hosting. The source is Apache-2.0, the build is a Next.js application with the validation service deployable as its own AWS infrastructure, and the Makefile exposes the build and test targets needed to run it yourself. A self-hosted instance removes the third-party question entirely. The badges work the same way either way, and here is the subtlety. A badge URL embeds a reference to a hosted configuration, so a documentation badge points at otelbin.io. If you self-host, your badge points at your instance. If your configuration changes, the badge changes, and a reader of the README sees the current pipeline rather than a picture of it from six months ago. The other thing to weigh is the alternative. Plenty of teams already keep Collector configuration in Git, run a Collector dry-run or a `validate` command in CI, and review the YAML in a pull request. For those teams, OTelBin's main value is the visualisation and the badge, and the validation is a convenience rather than a necessity. For a team that writes Collector configuration rarely, by hand, and deploys it into a cluster where a startup failure is discovered at the worst time, the validation is worth having on its own. ## Conclusion OTelBin suits an engineer who writes Collector YAML by hand and wants to see the pipeline shape and catch configuration errors before deploying to a cluster. It does not suit a team that keeps Collector configuration in Git with review and CI validation already in place, since it is an authoring and sharing tool rather than a source of truth, and it does not suit a workflow that must never send configuration to a third-party service. Verify first that the validation service accepts the collector components you use, since the checks come from a maintained component metadata set rather than from every collector version, and that the sharing feature, which requires signing in with a GitHub or Google account, fits your data handling rules. ## FAQ ### What is OTelBin? It is a configuration tool for OpenTelemetry Collector pipelines. It visualizes the configured pipelines as swimlanes, validates the configuration and highlights errors, and lets you share configurations online with a shareable link, which requires login with a GitHub or Google account. ### How does OTelBin validate a Collector configuration? The validation runs the configuration against OpenTelemetry collectors through a separate service, packaged as packages/otelbin-validation with a collector image in packages/otelbin-validation-image, and deployed on AWS Lambda. The checks rely on component metadata produced by cfgmetadatagen in its post-processed form from the nimbushq/otel-validator project. ### What is the OTelBin badge for? It renders your Collector configuration as an image you can embed in documentation, using shields.io-powered badges. It is offered in URL, Markdown and HTML form, and the badge points at the hosted configuration so the diagram in a README stays current instead of going stale. ### Can I self-host OTelBin? The source is Apache-2.0 licensed and the Makefile exposes install, test, lint, dev, build and coverage targets across the three packages, packages/otelbin, packages/otelbin-validation and packages/otelbin-validation-image. The hosted version is a Next.js application on Vercel with the validation service deployed on AWS Lambda. ### What technology does OTelBin use? The tech stack is Next.js as the framework, TypeScript as the language, Tailwind for CSS, ReactFlow for the visualisation, Upstash for Redis, Clerk for authentication, Vercel for hosting and privacy-friendly analytics, and AWS Lambda for validating configurations against OpenTelemetry collectors. ## Sources - [dash0hq/otelbin on GitHub](https://github.com/dash0hq/otelbin) - [Issues](https://github.com/dash0hq/otelbin/issues) - [License: Apache-2.0](https://github.com/dash0hq/otelbin/blob/main/LICENSE) - [Project website](https://www.otelbin.io) - [README](https://github.com/dash0hq/otelbin/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dash0hq-otelbin