Object Storage Backend (bundled MinIO or external/managed S3)

AnvilBase Storage (buckets, objects, image transforms, resumable uploads) is an S3 API facade. Out of the box it runs against the bundled MinIO service, so a single docker compose up is fully self-contained (“Local = Cloud”).

In production you can instead point AnvilBase at a managed, S3-compatible object store. The storage client is a generic aws-sdk-s3 (path-style) client, so any S3-compatible backend works. Doing so:

• removes the single-box storage SPOF (MinIO on one host),
• moves object I/O off the Postgres disk (less contention — relevant on networked/Ceph storage), and
• scales storage independently of the server.

Where this is configured — .env, not anvilbase.toml

This is server configuration: set it in the deployment’s environment (.env for Docker Compose, or the container environment: / Helm values.yaml).

anvilbase.toml is the CLI’s deploy-target manifest (which control-plane URL / project / token a developer’s anvilbase CLI talks to). It does not configure the server’s storage backend. Storage backend = server env vars.

Variable	Purpose
MINIO_ENDPOINT	the S3 endpoint URL of your object store
MINIO_ACCESS_KEY	S3 access key
MINIO_SECRET_KEY	S3 secret key
ANVILBASE_STORAGE_BUCKET_ENCRYPTION	on (default) applies SSE-S3 (put_bucket_encryption) to each new bucket. Set off when the backend doesn’t implement that API (then AnvilBase relies on the backend’s own at-rest encryption)

AnvilBase creates one bucket per project (bucket-<project_id>) automatically, so the credentials need create/delete-bucket + object read/write permissions. It signs with path-style addressing and region us-east-1 (harmless for non-AWS backends).

Provider quick-reference

Provider	MINIO_ENDPOINT	ANVILBASE_STORAGE_BUCKET_ENCRYPTION	Credentials
Bundled MinIO (default)	http://minio:9000	on	MINIO_ROOT_USER / MINIO_ROOT_PASSWORD
Infomaniak Public Cloud	https://s3.pub1.infomaniak.cloud (dc3-a; s3.pub2 for dc4-a)	off (Swift S3 gateway has no bucket-encryption API)	OpenStack EC2 credentials (below)
AWS S3	https://s3.<region>.amazonaws.com	on	IAM access key / secret
Cloudflare R2	https://<account_id>.r2.cloudflarestorage.com	off (R2 encrypts at rest; no put_bucket_encryption)	R2 API token (access/secret)
Backblaze B2	https://s3.<region>.backblazeb2.com	off	B2 application key
Scaleway	https://s3.<region>.scw.cloud	off	Scaleway API key

Rule of thumb: AWS supports put_bucket_encryption → leave encryption on. Most other S3-compatible gateways don’t → set it off and rely on their built-in at-rest encryption.

Example — Infomaniak Public Cloud

1. Generate S3 (EC2) credentials. The OpenStack application credential cannot mint these — log in with your user, then either use Horizon (Project → API Access → EC2 Credentials → Create) or the CLI:

   openstack ec2 credentials create   # prints `access` and `secret`

2. Point AnvilBase at it (.env):

   MINIO_ENDPOINT=https://s3.pub1.infomaniak.cloud        # dc3-a (use s3.pub2 for dc4-a)
   MINIO_ACCESS_KEY=<ec2 access>
   MINIO_SECRET_KEY=<ec2 secret>
   ANVILBASE_STORAGE_BUCKET_ENCRYPTION=false              # Infomaniak's S3 has no SSE-config API

3. docker compose up -d and create a throwaway project to confirm storage uploads/downloads work before moving real projects.

(The Swift-style URL https://s3.pub1.infomaniak.cloud/object/v1/AUTH_<project> is the Swift API; for the S3 client use the bare host above.)

Notes & caveats

• Migration: switching MINIO_ENDPOINT does NOT copy existing objects from the old MinIO. For an existing deployment, sync the data first (e.g. rclone/aws s3 sync between endpoints), then switch.
• Backups/PITR: wal-g/offsite backup targets are separate (WALG_S3_PREFIX, BACKUP_OFFSITE_*) and can use the same or a different store.
• aws-cli ≥ 1.37 forces aws-chunked encoding that some Swift gateways reject — that only affects the aws CLI, not AnvilBase’s SDK client.