S3 object storage

Koldan uses an S3-compatible object store for durable binary data. The chart can install MinIO or connect Koldan to an operator-managed S3-compatible endpoint.

Choose the deployment model

Set minio.install: true to install the chart dependency. Before using it for persistent environments, review its credentials, replica count, storage class and size, failure-domain placement, monitoring, and backup or replication design.

Set minio.install: false for an external service. Provision the bucket and identity first, then configure Koldan explicitly:

minio:
  install: false

config: |
  koldan:
    s3:
      enabled: true
      url: https://s3.example.net
      bucket: koldan
      access-key: <injected-access-key>
      secret-key: <injected-secret-key>

The supported Koldan contract is enabled, url, bucket, access-key, and secret-key. The url must be a complete endpoint that is compatible with the provider's S3 API and the installed release. There is no separate Koldan region or path-style property in this release; validate a non-MinIO service in a staging namespace before production rollout.

The credential placeholders must be populated through the controlled process in Configuration and secrets. Because config is rendered into a ConfigMap, a populated value is visible to subjects that can read it.

Provision access

Create the bucket before installation so its ownership, encryption, versioning, lifecycle, and location are deliberate. Grant the Koldan identity only the bucket-level and object operations required to check the bucket and create, read, list, and delete its objects. Include multipart-upload operations when the provider controls them separately. Do not grant account-wide storage administration.

Use TLS. For a private endpoint, make its CA available through TLS and custom CAs and keep hostname verification enabled. Configure encryption at rest and provider-side audit logging according to policy.

Koldan expects to control the lifetime of objects it owns. Do not add expiration, archival, object-lock, or replication rules until their behavior has been tested against Koldan retention and recovery procedures. A provider policy that expires a live object leaves its database record unusable.

Apply and verify

Before changing the endpoint, bucket, or credentials, back up the database and object data and preserve the rollback credential. After applying the Helm change:

• Confirm endpoint DNS, TCP, and TLS from the Koldan namespace.
• Confirm the configured identity can access only the intended bucket.
• Exercise an upload, download, range read where used, and deletion through Koldan.
• Confirm all affected pods are Ready and logs contain no signature, authorization, bucket, or certificate errors.
• Watch request latency, error rate, throttling, and object count during the rollout.

For credential rotation, allow old and new credentials to overlap where the provider supports it. Roll and test all affected workloads before disabling the old credential.

Capacity and recovery

Monitor usable capacity, bucket size, object count, request errors, latency, throttling, replication lag, credential expiry, and lifecycle actions. Alert before storage or provider quotas are exhausted. Include multipart uploads and non-current versions in capacity calculations where applicable.

Back up or replicate object data to meet the same recovery objectives as the Koldan database. During disaster recovery, stop or isolate writers and restore the database and objects to a mutually consistent point. Validate representative old and new objects after Koldan starts.