O11yLite: an OpenTelemetry backend that fits ingestion, storage, query and UI into one container

One container runs ingestion, storage, query and UI

The pitch is consolidation. Instead of a distributed fleet of indexers and query nodes, O11yLite runs the whole stack in a single process inside one container, and the quick start reflects that with a single image and a single volume:

docker run -d \
  -p 80:80 \
  -v o11ylite-data:/data \
  ghcr.io/o11ylite/o11ylite:latest

After that, the UI is at http://localhost, and OTLP exporters point at localhost:80. A built-in proxy routes both gRPC and HTTP on that same port, so a collector, an SDK exporter and a browser-facing client do not need separate listeners. The named volume is what keeps state across restarts, and the image is pulled from the ghcr.io registry rather than from a package index. The single port is the part worth planning around: it removes the usual split between an ingest listener and a query or UI listener, which is the main operational difference from a deployment made of several services.

Automatic schema evolution is the feature everything else leans on

The design bet is wide events over scattered logs: instead of dozens of narrow, context-free lines per request, a single rich record per unit of work carries user information, business data, feature flags and timings. That style only works if a field that appears for the first time can be queried immediately, and automatic schema evolution is the mechanism. New fields in incoming telemetry become queryable columns with no manual schema management, and the columnar storage underneath is designed for high cardinality. The stated test is blunt: send fifty-field spans and every field becomes queryable without configuration. Automatic schema evolution plus high-cardinality columnar storage is what makes that instrumentation style practical rather than aspirational.

Telemetry lands as open Parquet files through DuckDB and DuckLake

Storage is not a black box. Telemetry is stored as open Parquet files, handled through DuckDB and DuckLake, which is why the project argues that advances in embedded analytical databases mean a single process can handle work that used to need a cluster. The performance claims come with their conditions attached: the project says it sustains 140K events/s ingestion on a single M1 Max MacBook Pro and is built to realize the potential of a 7000 MB/s NVMe drive. The target audience is stated as teams from small startups through upper-mid-size organizations, one container and one volume with minimal moving parts.

The tagline says DuckDB and SQLite, the feature list says DuckLake

The storage story is named slightly differently in different places, and the difference matters when you are deciding what you are committing to. The project tagline credits DuckDB and SQLite as the engines, while the feature bullet names DuckDB plus DuckLake, and the storage bullet explains the consequence as telemetry held in open Parquet files. So the analytical engine and the file format are consistent across every mention, and the odd one out is SQLite, which appears in the summary line without a stated role next to the Parquet and DuckLake path. If your decision depends on which component owns your data on disk, the FAQ and the installation documentation are where to confirm it rather than the headline. Nothing in the repository states how the three names relate to each other at runtime.

Explore and notebooks both work on the same stored events

Querying and investigating are separate surfaces over the same data. Explore handles querying and visualizing traces, logs and metrics, with a built-in query builder and a trace waterfall view for reading a single request end to end. The query builder exists because of the wide-event stance: when every field on a span is already a column, the useful tool is one that lets you compose a filter over arbitrary field names without first writing a schema. Notebooks are for investigative work that outgrows one query: they compose and share workflows that combine queries with notes, so the reasoning behind an investigation travels with the queries it used instead of living in a separate document. Alert rules are the third surface, and they notify through Alertmanager-compatible webhooks, which means existing Alertmanager routing config can be pointed at the rule endpoints rather than replaced.

Agent access is built in with OAuth PKCE and a skill package

Agents get a first-class path rather than a scraped API. O11yLite ships built-in OAuth PKCE, plus an agent skill package documented at docs/agent-native.md that lets LLM agents query telemetry, manage alerts and edit notebooks out of the box. The project states the agent skill is considered a first-class interface, in the same category as the UI, and the reasoning is that agents work better against lean, solid primitives than against a bespoke integration for each model. The repository layout backs that up: a skills/ directory and an .agents/ directory sit next to AGENTS.md, CLAUDE.md and CLA.md, so the agent-facing assets are versioned with the rest of the project.

The image is built in three stages and runs under s6-overlay

The Dockerfile is explicit about how the single-process claim is assembled. Stage one compiles the TypeScript and React frontend with Vite on node:24-alpine, installing with npm ci before copying source so dependency layers cache. Stage two builds the Clojure uberjar on clojure:temurin-25-tools-deps, deliberately not an Alpine image because the grpc-java plugin requires glibc; it installs make, curl and unzip, takes the application version as a build argument defaulting to dev, and calls bin/deps-version through the Makefile to derive the protoc and grpc-java versions from deps.edn before downloading dependencies and compiling the OpenTelemetry protos into Java classes. Stage three is the runtime image, carrying s6-overlay, Caddy and a Java runtime.

AGPL-3.0, with commercial use arranged by contacting the maintainer

Licensing is the GNU Affero General Public License v3.0, free for both personal and commercial use under AGPL copyleft terms. The one caveat is stated plainly: for commercial use without AGPL obligations, the README directs you to contact zhming0. Deployment paths are documented in parallel, with docs/installation.md covering Docker and Helm chart setup, a separate page on collecting logs, traces and metrics from a Kubernetes cluster, docs/authentication.md covering OIDC setup, API keys and scopes, and a FAQ page. Development setup, architecture detail and the contribution workflow live in DEVELOPMENT.md and CONTRIBUTING.md rather than in the README, which keeps the README short at the cost of making the build story a separate read. The repository also carries a chart/ directory for Helm, a dev/ directory, docker-bake.hcl for image builds, a .buildkite/ directory for pipelines, renovate.json for dependency updates, a .tool-versions file, and .nvim.lua for editor tooling. The most recent releases are dated August 2026 and the last push was September 29, 2026.

Editorial conclusion

O11yLite fits teams that want traces, logs and metrics queryable from one place without standing up an indexer fleet, and that instrument wide events rather than dozens of narrow log lines. Read the AGPL terms first if you intend to modify it for a hosted product, since the commercial exemption is arranged by contacting the maintainer rather than by a permissive license. Before deploying, confirm your exporters can send OTLP/gRPC or OTLP/HTTP to the same port and decide where the mounted volume is backed up.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes