Skip to main content
Rootprint is a self-hosted log management platform: ingestion, full-text search, histograms, saved views, access control, and an HTTP API over your logs. It runs search directly on object storage by embedding Quickwit as its search and indexing engine.

​
The platform and its engine

Rootprint owns the entire log experience: who can sign in, which indexes they see, how each log renders, and the saved views, share links, and audit trail they build on top. For the heavy lifting of indexing and search, it drives an embedded Quickwit engine. Rootprint runs single-node; Quickwit scales horizontally. See Scaling beyond a single node. Quickwit has no authentication of its own: serve Rootprint on your public URL and keep Quickwit private.

​
How data flows

​
Ingest

  1. Producers push telemetry to Rootprint’s ingest gateway: OTLP logs at /v1/logs, OTLP spans at /v1/traces, or NDJSON logs at /api/ingest/ndjson. All three require an ingest API key (prefix rp_) that is scoped to exactly one index. That scope routes logs only — spans always go to the span store named by TRACE_INDEX_ID, whatever index the key is scoped to. See Traces.
  2. Rootprint authenticates the key and hands the data to its Quickwit engine’s ingest API. It does not transform the payload. The target index defines the schema.
  3. Pull-based sources (Kinesis, Kafka, S3/SQS) are the exception: you configure them through Rootprint, but Quickwit pulls that data directly from the source, bypassing the gateway.
  4. Quickwit indexers write the indexed data as splits to index storage and publish their metadata to the metastore.
See Send logs for the full list of ingestion paths.

​
Query

  1. A request arrives from the web UI (session cookie) or an external tool (query API key, prefix rpk_).
  2. Rootprint authorizes the request, reads its own application state from Postgres (saved views, preferences), and applies field-role mappings.
  3. Rootprint runs the search on its Quickwit engine, whose searchers read the metastore to plan the query, then read the relevant splits from object storage and return results.

​
What’s stored where

Three independent stores hold all durable state.
These three stores are separate from each other. Rootprint’s Postgres database and Quickwit’s metastore must each be their own database, even if they share a Postgres server. Back up all three: each holds state the others cannot reconstruct. Deleting the index-storage volume permanently destroys your logs.