Skip to main content

Bring your own storage FAQ

Bring your own storage (BYOS) keeps recordings in your cloud bucket while Foxglove operates indexing, query, and streaming in the same region. This page answers common questions. For setup steps, see Foxglove Cloud, bring your own storage.

Pricing and cost model​

How is bring your own storage billed?​

Foxglove bills two usage meters:

  • A one-time indexing charge per file
  • Bandwidth for data streamed or downloaded through Foxglove

Storage at rest, object GET/LIST requests, and any cross-region transfer are billed by your cloud provider, not Foxglove.

See Pricing for included usage and overage rates. The pricing page also includes a usage estimator.

Is storage decoupled from usage?​

Yes. After the one-time indexing charge, Foxglove doesn't charge for data that sits unqueried in your bucket. Bring your own storage doesn't add a Foxglove storage fee for data you already keep in your own cloud.

If data stays in the bucket, what is bandwidth?​

Bandwidth is bytes sent from Foxglove's query service to the client during visualization, search, or download. Data streams from your bucket, through Foxglove infrastructure in the site region.

Your cloud provider may also charge for reads from the bucket to the Foxglove query service, and for any cross-region transfer.

Does seeking or multiple users multiply bandwidth?​

Seeking within a visualization session makes use of a cache, but may fetch new data in some cases. Each additional user session viewing the same recording does fetch new data and count toward bandwidth.

Are downloads billed differently from streaming?​

No. Downloading and streaming use the same network access path, so both count toward bandwidth.

Who invoices for bring your own storage?​

Foxglove invoices indexing and bandwidth. Your cloud provider invoices storage at rest, bucket requests, and any cross-region transfer.

Setup and permissions​

What are the setup steps?​

  1. Create or choose a storage bucket.
  2. In Foxglove, go to Settings → Sites → Create site, then select your cloud provider and region.
  3. Grant read access to the bucket using the Foxglove identity shown on your site's details page.
  4. Configure an ingest path policy.
  5. Configure bucket notifications.
  6. Optionally, run a backfill to index recordings already in the bucket.

See setup for provider-specific commands.

What access does Foxglove need?​

Read-only access, scoped to that site's identity:

  • AWS: s3:GetObject and s3:ListBucket
  • GCP: roles/storage.objectViewer
  • Azure: Storage Blob Data Reader

Each site gets a unique identity. See Grant bucket access.

What if the AWS bucket uses a customer-managed KMS key?​

Add a KMS key policy statement that grants the site role kms:Decrypt and kms:DescribeKey, scoped to your bucket via kms:ViaService and kms:EncryptionContext:aws:s3:arn. See Grant bucket access for the statement.

How do notifications work?​

Foxglove indexes files when it receives a notification that an object was created, updated, or removed:

  • AWS: S3 Event Notifications to a Foxglove SNS topic
  • GCP: Pub/Sub notifications, including OBJECT_FINALIZE
  • Azure: Event Grid to a Foxglove webhook (configure a dead-letter container; Event Grid drops events after 24 hours of retries)

Notifications cover every object in the bucket. Foxglove checks each notified object's key against the site's ingest path policy and only indexes objects that match an Index rule.

See Configure bucket notifications.

Can indexing be triggered from a custom pipeline?​

Yes. POST to the /site-bucket-notifications API endpoint instead of relying on cloud-native bucket events.

Ingestion, metadata, and devices​

How do files get tied to projects and devices?​

Use the site's ingest path policy, metadata, or both:

  • Ingest path policy rules assign a device and project based on the object's key, for example naming the device after a directory in the path. This works for recordings that are already in the bucket and for files you can't add metadata to.
  • Object metadata or MCAP metadata records carry the project ID, device name or device ID, and session key in the file itself. See Adding metadata to imports for the full key list. Set this metadata when you write the object so Foxglove can associate the recording at index time.

Device and project assignments from the ingest path policy override object and MCAP metadata. Values provided in a /site-bucket-notifications API request override the policy's assignments. Metadata supplies anything a rule leaves unset. A project ID is required if neither the rule nor the metadata provides an existing device and your organization has multiple projects.

Can an existing bucket of recordings be connected?​

Yes. Connect the bucket and configure an ingest path policy and notifications. Foxglove indexes new objects when it receives a notification. To index objects that were already in the bucket, run a backfill from the site details page. A backfill applies the site's ingest path policy, and you can limit it to a key prefix. For a proof of concept, start with a small prefix.

warning

Use a backfill rather than updating object metadata to trigger notifications for existing objects. Updating metadata on existing objects is a billable event at your cloud provider. On Amazon S3 Intelligent-Tiering, a metadata update can also reset the object's storage tier, which can be expensive on large or infrequently accessed files.

Does unchanged data get re-indexed?​

No. Indexing runs when Foxglove receives a bucket notification for that object, or when a backfill finds it. A backfill skips objects that are already indexed. Unchanged files are not re-indexed and are not billed for indexing again.

What happens when a file fails to index?​

Foxglove retries failed imports automatically. If a file cannot be processed, or still fails after the retries are exhausted, the pending import is quarantined. The file itself is not moved or modified; it stays at its original path in your bucket.

Quarantined imports are listed in the Import Errors tab of the Recordings page along with the error message. From the menu at the right of the row you can download the file to diagnose it, or retry the import. See Diagnose and resolve errors for tips on repairing malformed files, and Quarantined files for how quarantine works across storage modes.

Playback and streaming performance​

Why is playback slow on bring-your-own-storage files?​

Bring your own storage uses index-in-place storage. Foxglove reads message data directly from your original files, so file layout may affect query latency.

Prepare MCAP files so that:

  • Chunks use lz4 or zstd compression
  • Chunks are 4 MB or less
  • High-bitrate topics (for example, images and point clouds) live in separate files from low-bitrate telemetry
  • Chunk indexes are present

See Optimize MCAP files for index-in-place and logging strategies.

Do existing files need to be reprocessed?​

No.

Can I use cold or archive storage?​

Foxglove can index and read a recording while your cloud provider makes its contents available to the site's read identity. Online cold storage tiers work, though your cloud provider may charge retrieval and request fees.

If you move an indexed recording to an offline archive tier, it remains listed in Foxglove, but playback, downloads, and queries that need message data are unavailable until you restore or rehydrate the file. Foxglove doesn't restore files from offline archive tiers. Automatic tiering policies may still change a file's tier based on access. Once your cloud provider makes the file readable again, Foxglove can read it again.

  • AWS: S3 Glacier Instant Retrieval is online. Files in S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, and the S3 Intelligent-Tiering Archive Access and Deep Archive Access tiers must be restored before reading them.
  • Google Cloud: Nearline, Coldline, and Archive storage remain online.
  • Azure: Cool and Cold access tiers are online. Rehydrate files in the Archive tier before reading them.

Security, compliance, and data residency​

What can Foxglove see?​

At index time, Foxglove stores metadata such as file path, hash, size, device name, time ranges, channel information (topic, schema, encodings). Message data may be read as part of indexing.

At query time, Foxglove's query service reads requested message data from your bucket and streams it to the authorized client.

Does Foxglove modify the data?​

No. Access is read-only. Foxglove doesn't mutate or move files. Recording lifecycle stays in your bucket. See How it works.

Does data stay in the bucket region?​

Indexing, query, and streaming run in the same cloud region as the site. Create the site in the same region as the bucket. A mismatch adds cross-region transfer cost and latency.

Visualization clients can be anywhere. Streaming to a client outside the site region counts toward Foxglove bandwidth and may also incur cloud-provider egress.

What about GovCloud, air-gapped, or classified environments?​

Those requirements typically need an on-premises Primary Site, where you run the data plane on your own Kubernetes cluster. Bring your own storage is a Foxglove-managed data plane reading from your bucket.

Deployment models​

Which deployment model should you choose?​

ModelData locationWho runs indexing, query, and streaming
Foxglove CloudFoxglove cloudFoxglove
Bring your own storageYour cloud bucketFoxglove (no Kubernetes or Helm)
On-premises Primary SiteYour infrastructureYou, in your Kubernetes cluster

See choosing a deployment model.

How does bring your own storage differ from an on-premises site?​

Both can use index-in-place storage. The difference is who operates the data plane: Foxglove for bring your own storage, your cluster for on-premises.

Bring your own storage bills Foxglove indexing and bandwidth for data you actually index and stream. Your cloud provider bills storage at rest.

What plan includes bring your own storage?​

Enterprise. Contact your Foxglove account executive to enable it for your organization.

Can recordings be deleted from inside Foxglove?​

No. Foxglove does not manage file lifecycle with BYOS. Delete files directly from the bucket; Foxglove removes them from the index when the files are gone. See Deleting recordings.

Supported providers and regions​

Which clouds are supported?​

AWS, Google Cloud, and Azure. Other object stores are not supported.

What region should my Foxglove site use?​

Create your Foxglove site in the same region as your bucket to avoid cross-region data transfer (egress) charges.

What if my region isn't listed?​

Contact Foxglove if your region isn't available in the site creation dialog.