Skip to main content
This page shows how to configure the AWS CLI and boto3 to interact with CoreWeave AI Object Storage, so you can use AWS tooling against CoreWeave endpoints. We recommend using a separate AWS profile for Object Storage to avoid conflicts with other AWS profiles and S3-compatible services. Both static credentials and Workload Identity Federation are supported, but we recommend Workload Identity Federation.

Static credentials

Static credentials are the simplest way to get started when you have an access key and secret key on hand. To set up your AWS configuration for Object Storage, create a new credentials file and profile.
  1. Create a new profile called cw:
  2. When prompted for information, provide the following values:
  3. Set the endpoint URL to the appropriate endpoint for your use case:
  4. Set the default addressing style to virtual. This is required for Object Storage.
With your profile in place, the AWS CLI is ready to issue commands against Object Storage using static credentials.

Workload Identity Federation in Kubernetes

This approach is best for workloads running inside CKS, where short-lived tokens are preferred over long-lived static credentials. When an OIDC token is available in a file and automatically rotated (as in Kubernetes and CKS), use the Container Credentials API. Start with a basic config file for the endpoints:
This produces a configuration like:
Then set the Container Credentials environment variables. These are often injected automatically by the Pod Identity Webhook. Replace [ORG-ID] with your CoreWeave organization ID. Your Org ID is a short hexadecimal string (for example, ab1cd2). Find it on the Settings page of your Cloud Console account.
The SDK reads the token from the file path and exchanges it for temporary credentials at the specified endpoint, then refreshes them automatically before expiry.

Workload Identity Federation with a credential process

Use this approach when you want federated credentials outside of CKS, such as on developer workstations or in CI environments. Without an auto-rotated token file, AWS SDKs support a Process Credential Provider that invokes a custom command to fetch credentials. This works for both human and machine workloads.
This produces:
When an S3 client invokes a command using this profile, it runs the specified script and expects output in this format:
The script implementation depends on your platform. It might perform an interactive browser sign-in, fetch a GitHub Actions ID token, or use another identity provider. The general pattern is:
  1. Check for cached credentials.
  2. Obtain a new OIDC token from your identity provider if the cached credentials are missing or expired.
  3. Exchange the token with the CoreWeave API for temporary credentials.
  4. Cache and return the response.

Boto3

This section covers how the same configuration applies when you use boto3 in Python.
If you use Workload Identity Federation, use boto3 >= 1.42.5, which incorporates a required fix for CoreWeave APIs.
Boto3 uses the same configuration files as the AWS CLI. If you have already configured the AWS CLI, no additional setup is needed. Boto3 can also use a Config object or the environment to override the AWS CLI configuration. See the full configuration examples.
Last modified on May 29, 2026