> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mixpeek.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Bring Your Own Object Storage

> Back the Mixpeek Vector Store with your own S3-compatible or GCS bucket on dedicated and self-hosted deployments

The Mixpeek Vector Store (MVS) persists everything it owns — the write-ahead log, snapshots, and the cold tier — to object storage through a provider-agnostic layer. On **dedicated and self-hosted deployments** you can point that layer at your own bucket, on any supported provider, so your vector data lives in storage you control.

<Note>
  This is about where MVS **stores its own data**, not where you ingest from. To connect a bucket as an ingestion *source*, see [Object Storage Integrations](/integrations/object-storage/overview). The managed shared plane uses Mixpeek-operated storage; BYO object storage applies to [single-tenant](/resources/single-tenant) and self-hosted deployments and is configured at the deployment level (not a per-namespace setting).
</Note>

## Supported providers

MVS speaks the S3 API (via boto3) and the native GCS API. Any S3-compatible store works through the same code path — the only per-provider differences are the endpoint, region, and path-style addressing.

| Provider             | `MVS_OBJECT_STORE_PROVIDER` | Docs                                                |
| -------------------- | --------------------------- | --------------------------------------------------- |
| Amazon S3            | `s3`                        | [S3](/integrations/object-storage/s3)               |
| Google Cloud Storage | `gcs`                       | [GCS](/integrations/object-storage/gcs)             |
| Cloudflare R2        | `r2`                        | [R2](/integrations/object-storage/r2)               |
| Tigris               | `tigris`                    | [Tigris](/integrations/object-storage/tigris)       |
| Wasabi               | `wasabi`                    | [Wasabi](/integrations/object-storage/wasabi)       |
| Backblaze B2         | `b2`                        | [Backblaze](/integrations/object-storage/backblaze) |
| MinIO                | `minio`                     | S3-compatible                                       |
| DigitalOcean Spaces  | `spaces`                    | S3-compatible                                       |
| Ceph                 | `ceph`                      | S3-compatible                                       |
| LocalStack (dev)     | `localstack`                | S3-compatible                                       |

See all providers in the [Object Storage overview](/integrations/object-storage/overview).

## Configuration

The object-store backend is resolved from environment variables on the MVS coordinator and shard pods:

| Variable                    | Default | Description                                                                                        |
| --------------------------- | ------- | -------------------------------------------------------------------------------------------------- |
| `MVS_OBJECT_STORE_PROVIDER` | `gcs`   | Provider key from the table above.                                                                 |
| `MVS_BUCKET`                | —       | Bucket that holds all MVS data. (Legacy alias: `MVS_GCS_BUCKET` — both must name the same bucket.) |
| `MVS_OBJECT_STORE_ENDPOINT` | —       | Custom S3 endpoint. **Required** for R2, Tigris, and Wasabi; optional for MinIO/Ceph.              |
| `MVS_REGION`                | —       | Region for S3-compatible providers.                                                                |
| `MVS_PREFIX`                | `mvs/`  | Global key prefix for all objects.                                                                 |
| `MVS_ENCRYPTION_KEY`        | —       | Optional base64-encoded 32-byte key to encrypt all data at rest (see below).                       |

<Warning>
  The coordinator and the Rust shard must read the **same** bucket. Set `MVS_BUCKET` (or `MVS_GCS_BUCKET`) consistently across both — a split here causes cross-tenant namespace discovery. MVS fails fast if the two env vars disagree.
</Warning>

### Credentials

Credentials are never stored in config — they're resolved from the deployment environment:

* **S3-compatible:** the standard AWS credential chain. Prefer an **IAM role** attached to the pods; otherwise set `AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY`. R2/Tigris/Wasabi/B2 issue S3 access keys you use the same way.
* **GCS:** Application Default Credentials (workload identity / `GOOGLE_APPLICATION_CREDENTIALS`), or a service-account JSON supplied as a secret.

### Endpoint and addressing notes

* **Endpoint required:** R2 (`https://<account_id>.r2.cloudflarestorage.com`), Tigris, and Wasabi have no usable default — set `MVS_OBJECT_STORE_ENDPOINT` or MVS fails fast with a clear message rather than silently hitting AWS.
* **Path-style addressing** is applied automatically for B2, MinIO, Ceph, and LocalStack (they only serve path-style); AWS/R2/Tigris/Wasabi use virtual-hosted style.

## Encryption at rest

Set `MVS_ENCRYPTION_KEY` (base64-encoded 32 bytes) to transparently encrypt every object with **AES-256-GCM**. The object's storage key is used as additional authenticated data (AAD), binding each ciphertext to its path. Migration is seamless: existing unencrypted objects stay readable while new writes are encrypted, so you can enable it on a populated bucket without a backfill.

## Examples

<CodeGroup>
  ```bash Amazon S3 theme={null}
  MVS_OBJECT_STORE_PROVIDER=s3
  MVS_BUCKET=my-mvs-data
  MVS_REGION=us-east-1
  # credentials via attached IAM role (recommended) or AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
  ```

  ```bash Cloudflare R2 theme={null}
  MVS_OBJECT_STORE_PROVIDER=r2
  MVS_BUCKET=my-mvs-data
  MVS_OBJECT_STORE_ENDPOINT=https://<account_id>.r2.cloudflarestorage.com
  AWS_ACCESS_KEY_ID=<r2_access_key>
  AWS_SECRET_ACCESS_KEY=<r2_secret_key>
  ```

  ```bash Google Cloud Storage theme={null}
  MVS_OBJECT_STORE_PROVIDER=gcs
  MVS_BUCKET=my-mvs-data
  # credentials via workload identity / GOOGLE_APPLICATION_CREDENTIALS
  ```

  ```bash MinIO (self-hosted) theme={null}
  MVS_OBJECT_STORE_PROVIDER=minio
  MVS_BUCKET=my-mvs-data
  MVS_OBJECT_STORE_ENDPOINT=https://minio.internal:9000
  AWS_ACCESS_KEY_ID=<minio_access_key>
  AWS_SECRET_ACCESS_KEY=<minio_secret_key>
  ```
</CodeGroup>

## Related

* [Object Storage Integrations](/integrations/object-storage/overview) — connect a bucket as an ingestion source
* [Single-Tenant Deployments](/resources/single-tenant) — fully isolated data plane with a dedicated bucket
* [Vector Store Overview](/vector-store/overview) — using MVS as a standalone vector store