Skip to main content
CaseBender storage is either a local Docker volume (the install default) or customer-owned external object storage. The application performs object data-plane operations only. It never creates, deletes, or configures a bucket or container at runtime. License (community or enterprise) does not choose the storage backend.

​
Current release status

The machine-readable authority is scripts/storage/certification-matrix.json:
The repository has emulator results, but emulator compatibility is not live certification. Current ODF/Ceph RGW live certification is pending customer-provided credentials and exact-version evidence. The profile is configured and qualification-ready, not certified.
“Implemented” means an adapter exists for object operations. “Declared supported” means the release matrix selects a product profile for a support gate. “Certified” additionally requires complete, signed live evidence for the exact product and version. Never infer certification from an adapter name, emulator run, Kubernetes render, or another customer’s result.

​
Configuration contract

Use a mounted STORAGE_CONFIG_FILE (preferred) or STORAGE_CONFIG_JSON with three profiles: quarantine, records, and ephemeral. The legacy single-profile bridge uses only these canonical provider IDs and variables:
  • s3: S3_BUCKET, AWS_REGION, optional HTTPS S3_ENDPOINT
  • gcs: GCS_BUCKET, optional GCS_PROJECT_ID
  • azure: AZURE_STORAGE_ACCOUNT, AZURE_CONTAINER
  • local: STORAGE_PATH (Compose default /data)
azure-blob, AWS_S3_BUCKET, and AZURE_STORAGE_CONTAINER are not valid runtime names. Installations must set an explicit storage provider. MinIO and HTTP custom endpoints are rejected. Local volume storage is a named Docker volume, independent of license. Use workload identity or the provider’s default credential chain. Static S3 keys, GCS key files, Azure shared keys, and Azure connection strings are compatibility modes only. Store any credentials in the platform secret manager; never place them in source, ConfigMaps, images, shell history, logs, evidence, or support bundles.

​
Required production boundary

  • Use pre-created external buckets or containers with no public access.
  • Separate quarantine, durable records, and ephemeral objects so retention, scanner, and expiry policy can differ.
  • Keep TLS verification enabled; mount private CA bundles when required.
  • Require encryption at rest and in transit, versioning, backups, and application SHA-256 verification.
  • Enable and qualify retention/legal-hold controls when the deployment requires WORM. Exact object versions are mandatory for retention and hold operations.
  • Do not enable signed URL, presigned URL, or SAS generation. Downloads pass through authenticated CaseBender authorization.
  • Configure external clamd; user uploads remain quarantined and unavailable when scanning cannot produce a terminal clean verdict.
  • Monitor readiness, deep-canary age, mutation dead letters, quarantine age, missing objects, confirmed orphans, checksum failures, latency, and capacity.
See Storage Security Baseline and Storage Health and Troubleshooting.

​
Qualification and change control

Validate from the same network, identity, endpoint, and CA context as the web and worker workloads. Re-run qualification after a CaseBender upgrade, provider upgrade, bucket-policy change, credential rotation, CA rotation, network-policy change, or WORM change.
Provider-specific live validation and signed evidence are required in addition to repository tests. See Provider Selection and Certification and S3-Compatible Certification.

​
Lifecycle references