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.

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.

   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.

   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.

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 base with a bucket source, for example, indexes new documents this way.

Bring data from another provider

Connect the source once in 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.

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.

Related

• Frazer Storage product page
• Volumes and snapshots for block and file storage
• Serverless for bucket bindings
• In-memory store for RDB import from a bucket
• Integrations for import sources
• Identity and access for project roles