Skip to main content
Use object storage for the data and system directories when running Cognee in distributed environments (containers, Kubernetes, multi‑node). Amazon S3 and any S3-compatible service (Cloudflare R2, MinIO, etc.) are supported today via the AWS_ENDPOINT_URL environment variable.

When to use

  • Containers/servers without a shared local disk
  • Centralized storage for data_root_directory and system_root_directory
  • Easy backups and lifecycle policies

Configuration

Use this for native AWS S3 buckets.
AWS_ENDPOINT_URL is not required for standard Amazon S3.For AWS-hosted deployments, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are optional when the runtime already has ambient AWS credentials. If both values are omitted, Cognee defers to boto3/s3fs’s default credential resolution chain, including EC2 instance profiles, ECS task roles, EKS IRSA (IAM Roles for Service Accounts), shared credentials files, and AWS_PROFILE.If you set either AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY explicitly, set both. AWS_SESSION_TOKEN is also supported when using temporary credentials.
The same STORAGE_BACKEND=s3 backend is used for all three options. For S3-compatible providers, Cognee relies on AWS_ENDPOINT_URL to route requests to the correct API endpoint.

Programmatic directories

Verify

How it works

AWS_ENDPOINT_URL is passed directly to s3fs as endpoint_url, which boto3/s3fs then uses instead of the default AWS endpoint. Any service that implements the S3 API will work.

Next steps

  • Short workflow: S3 Storage guide
  • Deployment variants: how-to-guides/cognee-sdk/deployment/index