CoreWeave
Search…
Object Storage
Learn about CoreWeave's S3 compatible Object Storage
Coreweave Object Storage is an S3-compatible storage system that allows data to be stored and retrieved in a flexible and efficient way. CoreWeave Object Storage also supports multiple regions, allowing you to utilize regionally optimized clusters for your needs. Additionally, because Object Storage works over HTTP, any compatible S3 CLI tool or SDK integration may be used in tandem with Object Storage.
To get started with Object Storage, simply generate a key pair, download your credentials, and start managing your data!
Note
When using AWS SDKs, the variable AWS_REGION is defined within the V4 signature headers. The object storage region for CoreWeave is named default.

Important
Object storage is currently in beta. To configure object storage, please contact support.
There are three designated storage classes for object storage formats, which correspond to regional object storage endpoints:
Storage class
Object storage endpoint
object-standard-ord1
object.ord1.coreweave.com
object-standard-las1
object.las1.coreweave.com
object-standard-lga1
object.lga1.coreweave.com
Each endpoint represents an independent, exclusive object store. This means that objects stored in ORD1buckets are not accessible from the LAS1 region, and so on.
Once access has been granted to your account by the CoreWeave support team, you will receive configuration files such as the example file shown below. These config files are used to authenticate to object storage by using the free s3cmd CLI tool.
After s3cmd is installed, the configuration file can be placed in the home directory with the filename .s3cfg (e.g., /home/.s3cfg).
Note
Configuration file paths may also be passed to s3cmd using the -config= option.
Example config file
[default]
access_key = 1K3R1P9903MEDQHZ71122
secret_key = fdsoie9FmSoXX2kOf6Ud0OFCQGw9323455sdfdssdae
host_base = object.lga1.coreweave.com
host_bucket = object.lga1.coreweave.com
# remove this if you configured SSL
check_ssl_certificate = True
check_ssl_hostname = True
Example s3cmd usage
$ s3cmd mb s3://my-new-bucket
$ s3cmd put my-file.txt s3://my-new-bucket
$ s3cmd --config=my-cfg-file mb s3://my-new-bucket
$ s3cmd get s3://my-new-bucket/my-file.txt
Users may use any regional Object Storage endpoint and create and use buckets as they wish, but each region comes with its own quota limit. The default quota limit is 30TB of data per region.
Note
Should you require an increase in your quota limit, please contact support.

Server Side Encryption is implemented according to AWS SSE-C standards.
CoreWeave supports Server Side Encryption via customer-provided encryption keys. The client passes an encryption key along with each request to read or write encrypted data.
No modifications to your bucket need to be made to enable Server Side Encryption (SSE-C) - simply specify the required encryption headers in your requests.
Important
It is the client’s responsibility to manage all keys, and to remember which key is used to encrypt each object.

The following headers are utilized to specify SSE-C customizations.
Name
Description
x-amz-server-side-encryption-customer-algorithm
Use this header to specify the encryption algorithm. The header value must be AES256.
x-amz-server-side​-encryption​-customer-key
Use this header to provide the 256-bit, base64-encoded encryption key to encrypt or decrypt your data.
x-amz-server-side​-encryption​-customer-key-MD5
Use this header to provide the base64-encoded, 128-bit MD5 digest of the encryption key according to RFC 1321. This header is used for a message integrity check to ensure that the encryption key was transmitted without error or interference.

The following example demonstrates using an S3 tool to configure Server Side Encryption for Object Storage.
Note
Because SSE with static keys is not supported by s3cmdat this time, the AWS CLI tool is used for this example. For a full explanation of the parameters used with the s3 tool in this example, review the AWS CLI s3 documentation.
First, run aws configure to set up access and to configure your Secret Keys.
$ aws configure
Separately, generate a key using your preferred method. In this case, we use OpenSSL to print a new key to the file sse.key.
$ openssl rand 32 > sse.key
Important
The generated key must be 32 bytes in length.
Once the process of aws configure is complete and your new key has been configured for use, run the following s3 commands to upload a file with Server Side Encryption.
$ aws s3 --endpoint-url=https://object.las1.coreweave.com \
cp your-file.txt s3://your-bucket/your-file.txt \
--sse-c-key=fileb://sse.key \
--sse-c AES256
Finally, to retrieve the file, pass the path of the encryption key used (sse-customer-key) to aws s3 to decrypt the file:
$ aws s3 --endpoint-url=https://object.las1.coreweave.com \
cp s3://your-bucket/your-file.txt your-file.txt \
--sse-c-key=fileb://sse.key \
--sse-c AES256

When an initial key pair is created for object storage access, that key pair is considered a Full User with access to read, write, and modify policies of the buckets which it owns.
The categories of access that can be granted are:
  1. 1.
    Read - Gives access to only read from buckets you own and have created.
  2. 2.
    Write - Gives access to only write to buckets you own and have created.
  3. 3.
    Write/Read - Grants access to both read and write to buckets you own and have created.
  4. 4.
    Full control - Grant Write/Read access, as well as admin access to create buckets and apply policies to buckets.
Each key pair is considered an individual user for access, and can be used to provide granular access to applications or users.

Currently, CoreWeave Cloud supports the following IAM bucket policy actions.
Click to expand - Supported IAM Actions
Important
CoreWeave Cloud does not yet support setting policies on users, groups, or roles. Currently, account owners need to grant access directly to individual users. Granting an account access to a bucket grants access to all users in that account.
For all requests, the condition keys CoreWeave currently supports are:
  • aws:CurrentTime
  • aws:EpochTime
  • aws:PrincipalType
  • aws:Referer
  • aws:SecureTransport
  • aws:SourceIpaws:UserAgent
  • aws:username
Certain S3 condition keys for bucket and object requests are also supported. In the following tables, <perm> may be replaced with either
  • read
  • write/read-acp
  • or write-acp/full-control
for read, write/read, or full control access, respectively.

s3:createBucket
s3:x-amz-acl, s3:x-amz-grant-<perm>
s3:ListBucket
s3:<prefix>
s3:ListBucketVersions
N/A
s3:delimiter
N/A
s3:max-keys
N/A
s3:PutBucketAcl
s3:x-amz-acl s3:x-amz-grant-<perm>

s3:PutObject
s3:x-amz-acl and s3:x-amz-grant-<perm>
s3:x-amz-copy-source
N/A
s3:x-amz-server-side-encryption
N/A
s3:x-amz-server-side-encryption-aws-kms-key-id
N/A
s3:x-amz-metadata-directive
Use PUT and COPY to overwrite or preserve metadata in COPY requests, respectively
s3:RequestObjectTag/<tag-key>
N/A
s3:PutObjectAcl
s3:x-amz-acl and s3-amz-grant-<perm>
s3:PutObjectVersionAcl
s3:x-amz-acl and s3-amz-grant-<perm>
s3:ExistingObjectTag/<tag-key>
N/A
s3:PutObjectTagging
s3:RequestObjectTag/<tag-key>
s3:PutObjectVersionTagging
s3:RequestObjectTag/<tag-key>
s3:ExistingObjectTag/<tag-key>
N/A
s3:GetObject
s3:ExistingObjectTag/<tag-key>
s3:GetObjectVersion
s3:ExistingObjectTag/<tag-key>
s3:GetObjectAcl
s3:ExistingObjectTag/<tag-key>
s3:GetObjectVersionAcl
s3:ExistingObjectTag/<tag-key>
s3:GetObjectTagging
s3:ExistingObjectTag/<tag-key>
s3:GetObjectVersionTagging
s3:ExistingObjectTag/<tag-key>
s3:DeleteObjectTagging
s3:ExistingObjectTag/<tag-key>
s3:DeleteObjectVersionTagging
s3:ExistingObjectTag/<tag-key>

Another access control mechanism is bucket policies, which are managed through standard S3 operations.
For example, a bucket policy may be set or deleted using s3cmd as shown below. Here, the example policy is first created:
$ cat > examplepol
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": ["arn:aws:iam:::user/fred:subuser"]},
"Action": "s3:PutObjectAcl",
"Resource": [
"arn:aws:s3:::happybucket/*"
]
}]
}
Then, the policy is applied using setpolicy:
$ s3cmd setpolicy examplepol s3://happybucket
Finally, the policy is deleted using delpolicy:
$ s3cmd delpolicy s3://happybucket
Note
Bucket policies do not yet support string interpolation.

The current price for object storage is $0.03 per GB per month.
Copy link
On this page
Storage classes
Server Side Encryption
Using Server Side Encryption with customer-provided keys (SSE-C)
Identity And Access Management (IAM)
IAM Actions
Bucket policies
Object Storage pricing