Skip to main content

Foxglove Cloud, bring your own storage

Set up a Foxglove Cloud Primary Site that reads data directly from your own cloud storage bucket. Foxglove manages all processing infrastructure — you provide the bucket and grant access.

note

Contact your Foxglove account executive to get access to bring your own storage for your organization.

Overview​

With Foxglove Cloud bring-your-own-storage, your recordings stay in your cloud storage while Foxglove operates the indexing, querying, and streaming services in the same cloud region. There's no Kubernetes cluster to deploy or Helm chart to manage.

For billing, metadata, performance, and security questions, see the bring your own storage FAQ.

The setup process:

  1. Create a storage bucket (or use an existing one)
  2. Create a site in the Foxglove app, selecting your cloud provider and region
  3. Grant read access to your bucket using the Foxglove identity shown on your site's details page
  4. Configure an ingest path policy that decides which objects Foxglove indexes and which devices they belong to
  5. Configure bucket notifications so Foxglove knows when new files arrive
  6. Optionally, run a backfill to index the files already in your bucket

Organization admins can follow these steps in the app: open the site from the Sites settings page and select Start setup.

How it works​

Bring-your-own-storage sites use index-in-place storage. Once bucket notifications are configured, the flow for each recording is:

  1. You upload a file to your bucket, which triggers a notification to Foxglove.
  2. Foxglove checks the object's key against the site's ingest path policy and skips objects the policy doesn't index.
  3. Foxglove's indexer reads metadata from the file — time ranges, topics, and channel information — and stores that index.
  4. When you visualize or query data, Foxglove's query service reads directly from the original file in your bucket.

The original recordings remain the only copy of your data. Foxglove never transcodes, duplicates, or moves your files. Recording lifecycle is entirely yours — delete a file from your bucket and Foxglove's index updates automatically.

Each site gets a Foxglove-provided read identity scoped to the cloud provider and region. Grant bucket access to the identity shown on the site details page.

Metadata sent to Foxglove​

At index time, Foxglove extracts and stores metadata such as time ranges, topic names, and channel information. At query time, Foxglove's query service reads message data directly from your bucket — message contents, sensor data, and attachments are never copied to Foxglove storage. See the Primary Sites FAQ (applicable to all deployment models) for the full list of metadata fields.

Prerequisites​

  • A cloud provider account (AWS, GCP, or Azure)
  • Organization admin access in Foxglove

Setup​

Create a storage bucket​

Create a cloud storage bucket for your recordings, or use an existing one.

tip

Foxglove reads directly from your original files, so file layout affects query performance. Before uploading:

  • Use lz4 or zstd chunk compression for MCAP files; use lz4 for ROS 1 .bag files (bz2 is not recommended)
  • Keep chunk sizes small (4 MB or less) to minimize query latency
  • Partition high-bitrate topics (for example, images, point clouds) into separate files from low-bitrate telemetry

See Optimize MCAP files for index-in-place for a follow-along example, or storage mode for a summary.

Create a site​

  1. Go to the Sites settings page
  2. Click Create site
  3. Select your cloud provider (AWS, GCP, or Azure)
  4. Enter your bucket details and region

No additional fields are required.

  1. Click Create

After creation, the site details page displays the identifiers and ready-to-run CLI commands you need for the next two steps. Enter your values below and the commands on this page will update automatically:

Bucket name:

IAM principal ARN:

SNS topic ARN:

Region:

Grant bucket access​

Grant Foxglove read access to your storage bucket. After granting access, select Verify bucket access in the app. This checks whether Foxglove can list objects in the bucket; it does not verify that notifications are configured or that every file can be read.

The service account is an IAM role ARN. Add a bucket policy granting it read access:

aws s3api put-bucket-policy --bucket <your-bucket> --policy '{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Principal": { "AWS": "<site-role-arn>" },
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::<your-bucket>", "arn:aws:s3:::<your-bucket>/*"]
  }
]
}'

Or apply through the S3 Console under your bucket's Permissions > Bucket policy section.

If objects are encrypted with a customer-managed KMS key, also add this statement to that key's policy:

{
"Sid": "AllowFoxgloveDataPlatformDecryptS3Objects",
"Effect": "Allow",
"Principal": { "AWS": "<site-role-arn>" },
"Action": ["kms:Decrypt", "kms:DescribeKey"],
"Resource": "*",
"Condition": {
  "StringEquals": { "kms:ViaService": "s3.<aws-region>.amazonaws.com" },
  "StringLike": {
    "kms:EncryptionContext:aws:s3:arn": [
      "arn:aws:s3:::<your-bucket>",
      "arn:aws:s3:::<your-bucket>/*"
    ]
  }
}
}

Configure ingest path policy​

A site's ingest path policy decides which objects in your bucket Foxglove indexes, and which device and project each recording belongs to. The policy is an ordered list of rules, and it applies to both bucket notifications and backfills. Configure it before you set up notifications: a site without a saved ingest path policy tries to index every object it's notified about.

To edit the policy, open your site's details page and select Configure ingest path policy (or Edit policy once a policy is saved). Only organization admins can edit the ingest path policy.

Each rule has a key pattern and an action:

  • Key pattern – An RE2 regular expression that Foxglove searches for in each object's key, relative to the bucket root. Patterns match anywhere in the key unless you anchor them, so use ^recordings/ to match only keys that start with recordings/. A single . matches every object.
  • Action – Index to index matching objects as recordings, or Ignore to skip them.

Each new rule defaults to the key pattern \.(mcap|bag)$, the Index action, and From metadata for the device. Foxglove can only index MCAP and ROS 1 .bag recordings, so this pattern matches those files and skips everything else in the bucket, such as calibration files or metadata sidecars. Narrow the pattern to the paths you want indexed, or keep it as is to index every recording in the bucket.

Foxglove evaluates rules in order, and the first rule that matches an object decides what happens to it. Objects that match no rule are skipped. Because an Ignore rule stops evaluation, put it ahead of a broader Index rule to exclude part of a prefix. A site can have up to 100 rules.

For Index rules, choose how Foxglove assigns matching recordings to a device:

  • From metadata – Use the device and project from the recording's object or MCAP metadata. You can optionally set a project for the rule.
  • Named from the path – Build the device name from the object key with a template, using $1 for the pattern's first capture group, $2 for the second, and so on. Foxglove creates the device in the rule's project if it doesn't exist. Requires a project.
  • An existing device – Assign every match to one device. Choose a project first, then pick one of its devices.

Device and project assignments from the ingest path policy take precedence over values in object metadata and MCAP metadata. Metadata supplies anything a rule leaves unset, such as a session key. See metadata precedence for the full priority order.

If you send notifications through the /site-bucket-notifications API endpoint, device and project values provided in the request take precedence over the policy's assignments. The ingest path policy still determines whether the object is indexed.

For example, these rules skip a scratch directory, then index each MCAP or .bag recording under logs/ and name its device after the first directory below logs/:

OrderKey patternActionDevice
1^logs/scratch/Ignore—
2^logs/([^/]+)/.*\.(mcap|bag)$IndexNamed from the path, with template $1

With these rules, logs/robot-7/2026-10-01.mcap is indexed for the device robot-7, logs/scratch/test.mcap is skipped, and logs/summary.mcap is skipped because it matches neither rule.

While you edit, Foxglove lists a sample of the objects in your bucket and previews which rule each one matches, so you can check the rules before you save the policy. The ingest path policy can't be edited while a backfill is running.

To manage the ingest path policy as code, use the site ingest path policy endpoints in the Foxglove API (/sites/{id}/ingest-path-policy).

Configure bucket notifications​

Foxglove needs to know when files in your bucket are added or removed. Some cloud providers can also notify Foxglove when files transition between storage tiers. The notification mechanism varies by cloud provider.

The commands below send notifications for every object in the bucket, not only recordings. Foxglove uses your site's ingest path policy to decide which notified objects to index, so save the policy before you set up notifications.

Configure S3 Event Notifications on your bucket for object change events, pointing to the Foxglove SNS topic ARN shown on your site's details page:

aws s3api put-bucket-notification-configuration --bucket <your-bucket> --notification-configuration '{
"TopicConfigurations": [
  {
    "TopicArn": "<foxglove-sns-topic-arn>",
    "Events": [
      "s3:ObjectCreated:*",
      "s3:ObjectRemoved:*",
      "s3:LifecycleExpiration:*",
      "s3:LifecycleTransition",
      "s3:IntelligentTiering",
      "s3:ObjectRestore:*"
    ]
  }
]
}'

Foxglove's SNS topic policy already permits your bucket to publish to it. You can also configure this through the S3 Console under Properties > Event notifications.

You can also notify Foxglove of new files directly via the /site-bucket-notifications API endpoint. This is useful if you want to trigger indexing from a custom pipeline rather than relying on cloud-native bucket events.

To test notifications, upload a supported recording that matches an Index rule, then confirm it appears on the Recordings page.

Manage data​

Uploading recordings​

Upload recordings directly to your storage bucket using your cloud provider's tools (for example, aws s3 cp, gcloud storage cp, or az storage blob upload). Once the bucket notification fires, Foxglove indexes the file if it matches an Index rule in the site's ingest path policy, and it appears on the Recordings page.

You can associate metadata with recordings using object metadata or MCAP metadata records. See the Primary Site metadata documentation (applicable to all deployment models) for details on supported keys and formats.

Index existing recordings​

Bucket notifications only cover objects written after the notifications are configured. To index recordings that were already in your bucket, run a backfill. Only organization admins can start a backfill, and the site needs a saved ingest path policy first.

  1. Open your site's details page and select Index existing recordings.
  2. Optionally, enter a Key prefix to backfill only part of the bucket. Leave it empty to backfill the whole bucket.
  3. Select Start backfill.

Foxglove lists the objects under the prefix and evaluates each one against the site's current ingest path policy, the same way it evaluates bucket notifications. Objects that are already indexed are skipped and aren't indexed or billed again. You can run another backfill later to index objects that a changed rule now matches. A backfill doesn't change the device or project of recordings that are already indexed.

To correct a device or project assignment for an indexed recording, update the ingest path policy, then send a new object_created notification for that object through the /site-bucket-notifications API endpoint. Use a new messageId so the notification isn't deduplicated.

The site details page shows the latest backfill's status, the number of objects scanned, and the number of failed imports. Select Cancel backfill to stop it. A site runs one backfill at a time, and the ingest path policy can't be edited while a backfill is running.

Failed imports​

If a file fails to index, Foxglove retries automatically. Files that still fail are quarantined and listed in the Import Errors tab of the Recordings page, where you can download the file or retry the import. Quarantine does not move or modify the file in your bucket. See What happens when a file fails to index?.

Deleting recordings​

Delete recording files directly from your storage bucket. Your bucket notifications tell Foxglove when a file is deleted, and Foxglove removes the recording once it confirms the file no longer exists.

You can also report a deletion directly by calling the /site-bucket-notifications API endpoint with notificationType set to object_removed. Foxglove does not scan your bucket for deleted files, so a recording stays listed until one of these notifications reaches Foxglove.

Site deletion​

When you delete a bring-your-own-storage site, Foxglove tears down the associated compute resources. You're responsible for:

  • Revoking the bucket access grant for the site's Foxglove read identity
  • Removing bucket notification configuration

Supported file formats​

Bring-your-own-storage sites support the same file formats as index-in-place on-premises sites:

  • MCAP files with chunk indexes
  • ROS 1 .bag files with an index section
tip

If a recording lacks an index section, rebuild it with mcap recover or rosbag reindex.

Other deployment models​

For a full comparison of all deployment models — including Foxglove Cloud and on-premises — see choosing a deployment model.

Support​

For assistance, contact support@foxglove.dev.