Announcing: Index-in-place for Self-hosted Sites.

When you run a self-hosted Foxglove Primary Site, you choose how much of your data lifecycle Foxglove should own. In the default query-optimized mode, uploads land in an inbox bucket and Foxglove rewrites them into a query-friendly layout in a lake bucket. That delivers strong query performance, but it also means Foxglove maintains a derived copy of your recordings.

Index-in-place is the alternative. It’s designed for teams that already treat their own object store as the system of record and don’t want Foxglove to ingest or rewrite those files. Instead of creating a lake, Foxglove builds metadata indexes over your existing bucket and reads directly from the original recordings at query time.

How index-in-place works.

With index-in-place, a Primary Site points at a single storage bucket that you control.

1. You upload MCAP files with chunk indexes or ROS .bag files with an index section to that bucket.
2. The site’s indexer reads metadata from each recording—time ranges, topics, offsets—and uploads that index into Foxglove.
3. When you open a timeline or panel, Foxglove’s query service uses this index to find relevant recordings and then reads data directly from those files in your bucket.

The index is metadata only. The payload bytes remain in your object store, and Foxglove never transcodes, re-chunks, or re-encodes those recordings into a second layout. Recording lifecycle is entirely yours: to remove a recording, you delete the file from the bucket and Foxglove’s view updates as the index catches up.

Because there’s no ingest pipeline, query behavior is determined largely by how your robots and logging jobs write recordings.

Preparing files for good query performance.

In a query-optimized site, Foxglove rewrites data into a layout that’s efficient for its query patterns. In index-in-place, that layout is whatever you already have. A few practices make a big difference:

Use appropriate compression: For MCAP, use chunk compression with lz4 or zstd. For ROS  bags, lz4 is preferred; bz2 is discouraged because it leads to higher latency and CPU cost at read time.

Keep chunks and files bounded: Use small, time-bounded chunks (on the order of < 1 MiB per chunk) and avoid very large, multi-day recordings. This limits the amount of data Foxglove must fetch and decompress for a time-bounded query.

Separate high-bitrate topics: Put high-bitrate streams like camera images and point clouds into separate recordings from low-bitrate telemetry. Otherwise, simple telemetry queries end up paying the cost of reading and decompressing large image chunks.

Tools like mcap info and mcap filter; rosbag reindex/mcap recover help you validate and adjust recordings before they ever reach the bucket.

If you already write logs this way for your own analysis, index-in-place lets Foxglove reuse that work instead of introducing a separate ingest step.

When index-in-place makes sense.

Index-in-place is a good fit when:

• Your robots and pipelines already write into an object store you treat as the canonical archive.
• Other tools (offline analysis, compliance workflows, custom scripts) rely on those same recordings.
• You want Foxglove to add visualization and interactive querying on top of that bucket, without becoming another data store to manage.

In that setup, a Primary Site configured for index-in-place simply adds a metadata layer and a query service in front of the bucket you already operate. You avoid duplicating data, avoid running an ingest pipeline, and keep your storage architecture aligned with the rest of your stack.

If you’d rather have Foxglove manage a query-optimized copy of your data, Foxglove’s Data platform is a better fit. In that setup, uploads land in an inbox bucket, Foxglove transcodes them into smaller, better-partitioned chunks in a separate lake bucket, and recordings become available to stream once they’re in that lake. Foxglove owns the derived data and its lifecycle.

Summary

Index-in-place gives Foxglove a way to sit directly on top of your existing recording archive. The indexer uploads metadata, the query service reads MCAP or ROS bag files straight from your bucket, and your original recordings remain the only source of truth.

If you already invest in writing well-structured logs, you can turn that archive into a self-hosted Primary Site with minimal extra infrastructure: configure the site for index-in-place, point it at your bucket, follow the file preparation guidelines, and Foxglove will query your recordings where they live.

Sign up to get started with Foxglove today or reach out to get a demo and to learn more about index-in-place.