CoreWeave AI Object Storage

Create a bucket

Create CoreWeave buckets outside BlixtFS. Creating a directory in the cloud root does not create one, and the CSI driver’s dynamic provisioning rejects cloud: "coreweave".

1. Choose the availability zone the bucket lives in, for example US-EAST-04A. BlixtFS signs requests with the zone as the region, so you will need it again when setting up credentials.
2. Create the bucket in the CoreWeave Cloud Console, or with the AWS CLI. The CLI needs a profile that points at the CoreWeave endpoint with virtual addressing, which cannot be set on the command line, and --region set to the zone so requests are signed with it:

aws configure --profile cw
aws configure set endpoint_url https://cwobject.com --profile cw
aws configure set s3.addressing_style virtual --profile cw
aws s3api create-bucket --bucket my-bucket \
  --region US-EAST-04A \
  --create-bucket-configuration LocationConstraint=US-EAST-04A \
  --profile cw

3. Refer to it in BlixtFS as cw://my-bucket.

Change notifications

CoreWeave does not support S3 event notifications, so BlixtFS receives none. Everything written through BlixtFS is visible immediately; changes made to the bucket outside BlixtFS — from another S3 client — appear only after the next fsck, never live. The event log does not apply to CoreWeave, and the bfs.object_etag extended attribute does not appear on CoreWeave files.

Endpoints

BlixtFS uses the primary endpoint, https://cwobject.com, which is reachable from anywhere over TLS 1.3. Inside a CoreWeave cluster there is also an in-cluster cache endpoint, LOTA (http://cwlota.com). BlixtFS can use it with --coreweave_use_lota, but it is off by default and unverified: whether LOTA serves the latest bytes right after an overwrite has not been tested.

Credentials and permissions

1. In the CoreWeave Cloud Console, create a static access key.
2. Copy the Access Key ID and Secret. These are S3-compatible credentials.
3. Create an organization access policy that grants the key access to your buckets. Nothing works until one does.
4. Enter the keys, along with the bucket’s availability zone, in BlixtFS during setup.

Only static keys are supported. Temporary keys, API-token exchange and Workload Identity Federation are not supported yet: they expire, and nothing refreshes them.

Environment variables

CoreWeave configuration does not use a credentials file. The zone and credentials are supplied as environment variables, or command-line flags. The BlixtFS config service never distributes the keys: every server that reaches a bucket needs them directly.

Required to serve a bucket

• COREWEAVE_ORGANIZATION_ID (--coreweave_organization_id) — your CoreWeave organization ID. It is the project your buckets are recorded under, as the account ID is for Cloudflare R2.
• COREWEAVE_AVAILABILITY_ZONE (--coreweave_availability_zone) — the availability zone requests are signed with, for example US-EAST-04A. It is validated at startup, and setting it turns the CoreWeave backend on.
• COREWEAVE_ACCESS_KEY (--coreweave_access_key) — the access key ID.
• COREWEAVE_SECRET_KEY (--coreweave_secret_key) — the secret key.

Optional

• COREWEAVE_BUCKETS (COREWEAVE_BUCKET) — buckets to serve, space-separated, instead of listing them as arguments: cw://my-bucket.
• --coreweave_use_lota — use the in-cluster LOTA cache endpoint. Off by default and unverified; see Endpoints above.

Summary

export COREWEAVE_AVAILABILITY_ZONE=US-EAST-04A
export COREWEAVE_ACCESS_KEY=your-access-key-id
export COREWEAVE_SECRET_KEY=your-secret-key

In Docker, pass them with -e; in Kubernetes, the Helm chart reads the keys from the bfs-coreweave Secret. Keep the secret key out of shell history and out of version control.