---
title: "Frazer Storage"
description: "S3 buckets in every Frazer region that your workloads reach with their own identity and no stored key, with versioning, Object Lock and lifecycle rules."
url: https://frazer.ai/docs/storage
index: https://frazer.ai/docs/llms.txt
tokens: 2284
---

> For agents: this page is indexed at https://frazer.ai/docs/llms.txt, and every page at https://frazer.ai/llms.txt. Copy commands from this file exactly.

# Frazer Storage

Frazer Storage is S3 object storage in every Frazer region, on servers Frazer runs. Your clusters and serverless services reach a bucket with their own identity, so no access key sits in your code, your Git repository or an image. Every bucket comes with versioning, Object Lock and lifecycle rules.

Product overview: [Frazer Storage](https://frazer.ai/storage).

## How it works

Each Frazer region has one S3 endpoint, `s3.us-virginia1.frazer.run`, which answers over IPv4 and IPv6. Any client that speaks the S3 API works: SDKs, command-line tools and backup tools. Underneath, your objects are replicated across the servers of the site, which Frazer runs for you: upgrades, disks and recovery.

Every project has its own bucket account, and your project roles map to roles on its buckets. A workload never holds a long-lived key. It presents its identity token from Frazer’s OIDC issuer to the region’s STS endpoint (`AssumeRoleWithWebIdentity`) and gets short-lived keys for the buckets it may use.

Each object is stored as three copies on three servers in the region, with a nightly copy at a second provider. Usage is metered as byte-hours every 60 seconds.

-   **Bucket**: a named container for objects in one region, owned by a project.
-   **Versioning**: an overwrite or a delete keeps the previous version until a lifecycle rule removes it.
-   **Object Lock**: a retention date on each object, in governance or compliance mode. A locked object cannot be deleted before its date.
-   **Lifecycle rule**: a schedule that expires old versions or aborts stale multipart uploads.
-   **Binding**: the link from a serverless service to a bucket, which writes the bucket’s variables into the service.

## Create a bucket

### Console

1.  Open **Data › Buckets** in your project and create a bucket.
    
2.  Choose versioning, an Object Lock mode and period if the data must not be deleted early, and lifecycle rules.
    
3.  Give access to the identities that need it: a cluster’s identity, or a serverless service. The bucket list shows each bucket’s size, objects, lock, rules, the identities that may reach it and its off-site copy.
    

### Stack

1.  Declare the bucket next to the service in your stack, and bind them.
    
    ```yaml title="frazer.stack.yaml"
    apiVersion: frazer.ai/v1
    kind: Stack
    name: notes
    services:
      notes-api:
        source: { repo: acme/notes, branch: main }
        bind: { S3_BUCKET: bucket/notes-uploads }
    buckets:
      notes-uploads: { versioning: true }
    ```
    
2.  Preview the stack’s plan, then run the command again without `--dry-run` to create it.
    
    ```sh
    frazer serverless stacks create notes --from frazer.stack.yaml --dry-run
    ```
    
3.  The binding grants the service access and writes `S3_BUCKET`, `AWS_ENDPOINT_URL_S3` and `AWS_REGION` into it.
    

### Use it from your code

Use any S3 SDK and leave out the access key: the SDK picks up short-lived credentials from the workload’s identity.

```py title="upload.py"
# S3_BUCKET, AWS_ENDPOINT_URL_S3, AWS_REGION
# come from the binding. Credentials are short-lived and
# come from the service's own identity: no access key.
import os
import boto3

s3 = boto3.client("s3")
s3.upload_file("note.md", os.environ["S3_BUCKET"], "notes/note.md")
```

> **Tip:**
> 
> There is nothing to rotate. Credentials from STS are short-lived by design, and a new workload identity gets its own.

## Write only if nothing changed

`PUT` with `If-None-Match: *` creates an object only if it is absent, and `If-Match: <etag>` replaces only that version; a mismatch returns `412`, so two writers never overwrite each other unseen. Lists come back in a stable order, with path-segment prefixes.

## Keep what you store

| Protection | What it does |
| --- | --- |
| Versioning | Keeps every previous version of an object until a lifecycle rule removes it |
| Object Lock, governance mode | Keeps each new object for a set period |
| Object Lock, compliance mode | Keeps each new object for a set period; changing the lock needs an approved plan |
| Lifecycle rules | Delete noncurrent versions a set number of days after they are replaced; abort incomplete multipart uploads |
| Server-side encryption | Objects encrypted with keys held in Frazer Secrets |

Every bucket aborts incomplete multipart uploads after 7 days by default. A typical rule set for a database backup bucket:

-   Delete noncurrent versions 30 days after they are replaced, which leaves a window to undo a delete.
-   Abort incomplete multipart uploads after 7 days.
-   Object Lock in compliance mode, 30 days on every new object.

## Get notified about changes

Buckets send persistent notifications when objects change, through Frazer’s event bus. Use them to start work when a file lands: a [Knowledge](https://frazer.ai/docs/knowledge) base with a bucket source, for example, indexes new documents this way.

## Bring data from another provider

Connect the source once in [Integrations](https://frazer.ai/docs/integrations), read-only, and copy the objects into a Frazer bucket. The connection can keep syncing during a migration window, 90 days by default, and then expires.

-   S3-compatible storage, including R2, B2, Wasabi and MinIO: OIDC federation where the provider offers it, otherwise an access key.
-   Google Cloud Storage, read-only with OIDC federation.
-   Azure Blob Storage, with a federated credential.

## Access and audit

| Who | What they can do |
| --- | --- |
| Project roles | Map to roles in the project’s own bucket account |
| Workloads | Reach the buckets they are bound to with their own identity, through STS |
| Changing a compliance-mode lock | Needs an approved plan |

-   Every bucket, rule and lock change is a plan with an audit entry.
-   Each lifecycle expiry shows in the console.
-   Usage is metered as byte-hours every 60 seconds and reconciled when the interval closes.

At a budget cap, buckets keep serving. Writes are blocked only after an invoice is 30 days past due, and deleting stored data needs a separate 30-day notice.

## Limits and quotas

| Item | Value |
| --- | --- |
| Copies | Three, on three servers in the region, plus a nightly off-site copy |
| Endpoint | `s3.us-virginia1.frazer.run`, IPv4 and IPv6 |
| Object Lock modes | Governance and compliance |
| Incomplete multipart uploads | Aborted after 7 days by default |
| Over quota | Writes return `403 QuotaExceeded` |
| Metering | Byte-hours every 60 seconds |

Frazer does not claim eleven nines of durability or durability across zones. What it states is what it runs: three copies in the region and one off-site.

## Pricing

Frazer Storage bills by the GiB-month stored, with no egress fees within fair use. The backups Frazer keeps for your databases and VMs come out of an allowance for every server you bring.

| Frazer Storage | On your servers | On the Frazer fleet |
| --- | --- | --- |
| storage, backups | Your disks · 100 GB backups per server included | $0.012 / GiB-month for objects, volumes of every class and backups |

Every line, with the estimator: [pricing](https://frazer.ai/pricing#lines).

## Troubleshooting

| Symptom | Cause | Fix |
| --- | --- | --- |
| A write returns `403 QuotaExceeded` | The project is at its storage quota | Delete objects or old versions, add a lifecycle rule, or ask for a higher quota |
| A workload is refused by a bucket | Its identity has no access to that bucket | Bind the service to the bucket, or grant the cluster’s identity access |
| Storage keeps growing after deletes | Versioning keeps every previous version | Add a rule that deletes noncurrent versions after a set number of days |
| An object cannot be deleted | It is under Object Lock until its retention date | Wait for the date; a compliance lock changes only through an approved plan |
| Your code asks for an access key | The SDK is not using the workload’s identity | Remove the static key and let the SDK read the identity token |

## Reference

### Errors

| Reason | What it means | How to fix it |
| --- | --- | --- |
| `QuotaExceeded` | A write would take the project past its storage quota. S3 clients get it as HTTP 403. | Delete objects or old versions, add a lifecycle rule that expires them, or ask for a higher quota. |

All of them: [Errors reference](https://frazer.ai/docs/errors).

## Related

-   [Frazer Storage product page](https://frazer.ai/storage)
-   [Volumes and snapshots](https://frazer.ai/docs/volumes) for block and file storage
-   [Serverless](https://frazer.ai/docs/serverless) for bucket bindings
-   [In-memory store](https://frazer.ai/docs/memory) for RDB import from a bucket
-   [Integrations](https://frazer.ai/docs/integrations) for import sources
-   [Identity and access](https://frazer.ai/docs/iam) for project roles

## Pages in Data

- [Databases](https://frazer.ai/docs/databases.md)
- [In-memory store](https://frazer.ai/docs/memory.md)
- [Frazer Storage](https://frazer.ai/docs/storage.md) (this page)
- [Secrets](https://frazer.ai/docs/secrets.md)
- [Volumes and snapshots](https://frazer.ai/docs/volumes.md)