Rootprint: A Low-Cost Open-Source Log Search Tool Built on S3 Object Storage
A solo-built open-source log search tool using Quickwit + S3 for full-text search at minimal cost.
Rootprint is an open-source log and trace tool built by an independent developer to manage IoT cluster logs — prioritizing true inverted index full-text search, multi-year low-cost retention, and single-person operability. Using Quickwit as its search engine with indexes stored on S3, it achieves storage-compute separation, enabling ~$300/month for two years of tens-of-terabytes retention. On top of Quickwit, it adds a full UI covering log search, saved views, context viewing, OpenTelemetry tracing, basic APM, and UI-based ops management. It intentionally excludes metrics, positioning itself as a lightweight ELK alternative for small teams.
Why One Developer Built Rootprint
Open-source observability tools are a dime a dozen, but products designed specifically for "one person can maintain this" scenarios are rare. Rootprint is exactly that — an open-source log and trace search tool built by an independent developer, with one standout feature: index files are stored directly on S3-compatible object storage, dramatically reducing the cost of long-term log retention.
The author's motivation came from a concrete problem: he runs a fleet of IoT devices (what he calls a "cool robot hive") that continuously generate large volumes of messy, unstructured logs — and he needed a system to store and search years worth of them.
His core requirements were clear:
- True inverted index search, not just label-based indexing
- Long-term retention at a manageable cost
- Fast full-text search across a massive haystack
- Single-person operable — it can't become a second full-time job
Why the Popular Alternatives Didn't Cut It
Before building his own tool, the author systematically evaluated several mainstream log management solutions. His "here's why I didn't choose the others" framing is genuinely useful for anyone doing their own evaluation.
Loki: Label-Only Indexing Falls Short for Full-Text Search
Loki indexes labels, not log content. The moment you need to search beyond those labels, performance degrades noticeably. As the author puts it: Loki is great when you already know which log stream to query, but "when you don't know where to look — which is most searches — it falls short."
Loki's design philosophy follows Prometheus's label model — it deliberately avoids full-text indexing of log bodies to achieve minimal storage overhead and operational complexity. Queries use LogQL, which requires narrowing down log streams via labels before applying regex or keyword filters (called "log filters") to stream content. This works well when logs are structured and labels are thoughtfully designed. But for diverse, unstructured sources like IoT device output — where defining meaningful labels upfront is difficult and cross-stream full-text search is essential — performance degrades linearly with log volume. That's the fundamental reason Loki excels at "known log streams" but struggles with "needle in a haystack" scenarios.
ELK: Powerful but Operationally Overwhelming
ELK's full-text search capabilities are unquestionable, but for a single person, the moving parts — nodes, shards, heap memory, ILM (Index Lifecycle Management) — are just too much. The author put it plainly: "I didn't want it to become my second job." For individuals or small teams, the operational burden of ELK is simply too heavy.
VictoriaLogs: Local Disk Creates a Storage Cost Ceiling
The author actually speaks highly of VictoriaLogs and uses it in other contexts. The problem: it currently stores data on local disk, and while object storage support is on the roadmap, it hasn't landed yet. That means long-term retention still requires paying for EBS volumes — which is precisely the cost pain point he was trying to solve.
Core Architecture: Quickwit + S3 Object Storage
The solution that finally met his needs was Quickwit, another excellent open-source search engine. It provides true inverted index search with index files stored in object storage, enabling queries to read directly from S3 buckets.
The cost advantages of this architecture are striking. Here's the author's actual production data:
| Metric | Value |
|---|---|
| Daily raw log volume | ~100 GB |
| Compression ratio | ~5.5x |
| Retention period | 24 months |
| Monthly S3 cost | ~$300 |
For two years of log retention totaling tens of terabytes, $300/month is extremely competitive. This is the core value of storing indexes in S3: storage and compute are fully decoupled, so cold data no longer drains your budget.
Quickwit uses a storage-compute separation architecture that's fundamentally different from traditional search engines like Elasticsearch, which tightly couple indexes and compute on local disk. It splits inverted indexes into immutable "splits" and uploads them directly to object storage (S3, GCS, Azure Blob, etc.). At query time, compute nodes pull only the needed index chunks on demand and release them when done. This means "almost no compute cost when there are no queries" — for long-tail historical data that's rarely accessed, storage costs approach the price of pure object storage (S3 standard is roughly $0.023/GB/month), with no need to pay for continuously running Elasticsearch nodes or EBS volumes. That's the fundamental reason the author can maintain two years of tens-of-terabytes log retention for around $300/month.
What Rootprint Adds on Top of Quickwit
If Quickwit already solves the search engine problem, why build Rootprint on top of it? The answer is day-to-day usability. Quickwit ships with only a very basic UI, and the author used Grafana's Quickwit plugin for a while, but it "only searched — nothing else."
Since his team works with these logs every day, he built a complete working interface on top of Quickwit. Key features include:
- Log search: field sidebar, click-to-filter, histogram visualization
- Saved views: persist query conditions, filters, sort order, and column configuration
- Context viewer: configurable context around a log line, plus a traceback tab for stack traces
- Traces & APM: OpenTelemetry traces displayed alongside logs, with basic span-based APM analysis
- Flexible ingestion: supports OTLP, HTTP NDJSON, and pulling from Kafka, Kinesis, or SQS/S3
- Auth & access control: scoped ingest keys, Google and GitHub OAuth login
- UI-based ops: indexes, mappings, field configuration, and retention policies all manageable from the interface
The entire product is built around OpenTelemetry, though most features work equally well with custom-structured data.
Scope and Tech Stack
The author is refreshingly honest about what Rootprint is and isn't. It does not include metrics — it only handles logs and traces. If you need metric dashboards and alerting, you'll still need Prometheus, Grafana, or similar tools alongside it. Rootprint doesn't try to be an all-in-one observability platform; it focuses on doing log search and distributed tracing well.
The tech stack is intentionally lightweight:
- API layer: Bun + Hono
- Frontend UI: SvelteKit
- Metadata storage: PostgreSQL
- Search engine: Quickwit
- License: Apache 2.0
The project includes a live demo with real data so developers can evaluate it quickly.
AI-Assisted Development and Project Positioning
The author is upfront about the project's current state: it's the work of a solo developer, with team help on QA, and he "expects bugs, rough edges, and some awkward UI." He explicitly doesn't claim feature parity with Grafana, VictoriaLogs, or ELK — this is a passion project from someone with 8+ years of infrastructure experience.
In response to earlier criticism about being "weekend vibe-coded," the author openly addressed AI involvement: Claude Code wrote portions of the project, which he continuously refactors and uses for initial code review. But he emphasizes that the core logic and architecture came from him and were written primarily by hand. He openly describes it as an "AI-assisted" open-source project.
Who Should Consider Rootprint
Rootprint's value isn't in displacing ELK or Grafana — it's in precisely addressing a neglected use case: individuals or small teams who need low-cost, long-term, full-text-searchable log systems without heavy operational investment.
By leveraging Quickwit's object storage indexing and adding a practical search-and-tracing interface on top, Rootprint delivers capabilities that previously required heavy-weight solutions — at a fraction of the cost. If any of the following describe you, it's worth adding to your evaluation list:
- IoT devices or edge computing generating large volumes of unstructured logs
- Audit logs that need to be retained for months or years
- Looking to replace expensive EBS volumes with S3-compatible object storage
- Seeking a lightweight open-source alternative to ELK
Background: OpenTelemetry Explained
OpenTelemetry (OTEL) is a CNCF-led unified standard for observability data, defining data formats and collection protocols for three signal types: Traces, Metrics, and Logs. OTLP (OpenTelemetry Protocol) is the standard data transport protocol, supporting both gRPC and HTTP/JSON. A Span is the basic unit of distributed tracing, representing the start time, end time, and context of a single operation; multiple Spans are linked by Trace ID to form a complete call chain.
Building Rootprint around OTEL matters because logs and trace data can share the same Trace ID — allowing developers to jump directly from an error log to the full call chain that produced it. This dramatically reduces time-to-diagnosis without manually correlating data across separate tools.
Related articles
Altman Rarely Admits Mistake: AI Disruption Is Far Slower Than Expected, Economic Inertia Severely Underestimated
OpenAI CEO Sam Altman admits he misjudged how fast AI would disrupt the economy, citing massive inertia in business behavior. A signal that the industry's narrative is maturing.
Blind Test Reveals: Why Students Prefer Gemini's Writing Over ChatGPT
A blind test found students preferred Gemini-generated academic essays over ChatGPT and Claude. Explore writing style differences and what this means for AI tools in education.
Trailmarks Review: A Travel Puzzle Game Built on Real-World Routes
Trailmarks is an iOS travel puzzle game built on real airline routes and geography. Covers 1,000+ cities, fully offline, one-time $4.99 purchase. Full review inside.