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

# Bring Your Own Bucket

> Host an Infino Cloud database in your own S3, GCS, or Azure bucket — your data stays in your account, reached through an identity you authorize, while Infino runs the control plane and serving layer.

By default, an Infino Cloud database stores its data in Infino's own object
storage, isolated by prefix. With **bring-your-own-bucket (BYOB)** you instead
point the database at **your own** S3, GCS, or Azure bucket. Your data stays in
your account; Infino reaches it through an identity **you authorize** and can
revoke, and the control plane and serving layer run as usual on top.

> [!NOTE]
>
> **BYOB is an enterprise feature.** It is enabled per account by Infino, not
> self-serve — [contact your Infino representative](https://infino.ai/talk) to turn
> it on. Until it is enabled, creating a database with a storage binding returns a
> `403`.

> [!NOTE]
>
> BYOB is the foundation for
> [Customer-Managed Encryption Keys](https://infino.ai/docs/cloud/customer-managed-keys.md): a key you
> control only encrypts a bucket you own, so CMEK is configured on a BYOB database.

## How it works

* **You grant one Infino identity access to your bucket** — an IAM role Infino
  assumes (S3), a service account you grant an object role (GCS), or an Entra
  application you consent (Azure). Infino provides the exact identity for your
  account; nothing secret is exchanged, and the grant is scoped to your bucket.
* **You register the bucket when you create the database.** `POST /v1/databases`
  carries a `storage` binding naming the bucket and how Infino is authorized.
* **Infino verifies access before serving.** A one-time probe writes and reads
  back a small object to confirm the grant works. Until it passes, the database
  does not serve.

Everything Infino writes — the index, its Parquet data — lands in your bucket. You
can revoke Infino's access at any time by removing the grant, independently of
Infino.

> [!WARNING]
>
> Obtain the Infino identity to authorize (the S3 principal ARN, GCS service account,
> or Azure application id) from the Infino console or your Infino representative — it
> is specific to your account and deployment. The examples below use placeholders.

## AWS (Amazon S3)

AWS setup is two-phase because the **external id** that protects the role against
confused-deputy use is generated by Infino when you create the database.

**1. Create an IAM role Infino can assume**

Create an IAM role in your account whose **trust policy** allows the Infino
principal to assume it. Grant the role read/write access to your bucket (an
`s3:*Object` policy scoped to the bucket and prefix, plus
`s3:GetEncryptionConfiguration` on the bucket).

**2. Register the database with the role**

```jsonc theme={null}
POST /v1/databases
{
  "name": "my-database",
  "storage": {
    "provider": "s3",
    "bucket": "my-bucket",
    "region": "us-east-1",
    "role_arn": "arn:aws:iam::123456789012:role/your-infino-byob-role"
  }
}
```

The response returns a one-time **`external_id`**:

```json theme={null}
{ "storage": { "external_id": "a1b2c3…", "verified": false } }
```

**3. Add the external id to the role's trust policy**

Add an `sts:ExternalId` condition to the role's trust policy, set to the
`external_id` from the previous step. This ensures only Infino acting **for your
database** can assume the role — not a different tenant or a replayed request.

**4. Verify**

```jsonc theme={null}
POST /v1/databases/my-database/storage/verify
```

Infino runs the bind-time probe. On success the database serves; if the trust
policy or bucket permissions are incomplete, fix them and verify again.

## GCP (Google Cloud Storage)

**1. Grant Infino's service account access to your bucket**

Grant Infino's service account `roles/storage.objectAdmin` on the bucket that will
hold the database's data. (Infino gives you the service-account address for your
account.)

**2. Register the database**

```jsonc theme={null}
POST /v1/databases
{
  "name": "my-database",
  "storage": {
    "provider": "gcs",
    "bucket": "my-bucket",
    "region": "us-central1"
  }
}
```

Because the grant is already in place, Infino runs the verification probe at
create time, and the database serves once it passes.

## Azure (Azure Blob Storage)

**1. Consent Infino's application and grant it a data role**

**Admin-consent** Infino's Entra application in your tenant, then grant it a data
role (such as **Storage Blob Data Contributor**) on the storage account holding
your container. (Infino gives you the application id for your account.)

**2. Register the database**

```jsonc theme={null}
POST /v1/databases
{
  "name": "my-database",
  "storage": {
    "provider": "azure",
    "container": "my-container",
    "region": "eastus",
    "tenant_id": "<your-entra-tenant-id>"
  }
}
```

Infino verifies access and the database serves once the probe passes.

## Optional: a prefix

Every provider accepts an optional `prefix` — a root inside the bucket or container
under which everything Infino writes lives, so a BYOB bucket can be shared with
other data:

```jsonc theme={null}
"storage": { "provider": "s3", "bucket": "my-bucket", "region": "us-east-1",
             "role_arn": "…", "prefix": "infino/my-database" }
```

## Encrypting with your own key

To encrypt a BYOB database's data with a key **you** own and control in your cloud
KMS — and be able to revoke Infino's access to the data independently of Infino —
see [Customer-Managed Encryption Keys](https://infino.ai/docs/cloud/customer-managed-keys.md). CMEK adds an
`encryption` block to the same `storage` binding shown above.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.