41 lines
1.8 KiB
Markdown
41 lines
1.8 KiB
Markdown
# 0004: Replace unmaintained MinIO baseline
|
|
|
|
- Status: Accepted
|
|
- Date: 2026-07-12
|
|
|
|
## Context
|
|
|
|
The original Ekklesia brief selected MinIO as the default self-hosted S3-compatible service. The
|
|
upstream `minio/minio` repository was archived on April 25, 2026 and states that historical
|
|
community binary releases are no longer maintained. New church deployments may store highly
|
|
sensitive content, so beginning on an unmaintained security-sensitive service is unacceptable.
|
|
|
|
## Decision
|
|
|
|
Keep Ekklesia's future storage contract provider-neutral and use SeaweedFS 4.28 in the Phase 1
|
|
development Compose environment. SeaweedFS is actively maintained and offers an S3-compatible
|
|
endpoint and a small single-node development mode.
|
|
|
|
Before treating any provider as production-ready, add storage contract tests covering put, get,
|
|
head, delete, ranges, multipart uploads, metadata/content type, signed URLs, bucket and prefix
|
|
isolation, and denied access. A production provider decision remains separate.
|
|
|
|
## Alternatives
|
|
|
|
- Retaining the final MinIO community image was rejected because it no longer receives upstream
|
|
maintenance.
|
|
- Provider-specific Core APIs were rejected because they would couple every module to this choice.
|
|
- Deferring all object storage was rejected because a reproducible S3 development endpoint is part
|
|
of the repository foundation.
|
|
|
|
## Consequences
|
|
|
|
The implementation intentionally uses `S3_*` configuration rather than `MINIO_*` names. Some
|
|
SeaweedFS behavior may differ from AWS S3 or historical MinIO and must be captured by contract
|
|
tests before the storage abstraction is implemented.
|
|
|
|
## Migration implications
|
|
|
|
No product data exists in Phase 1. Later provider changes must follow an object-copy and integrity
|
|
verification plan while preserving stable Core storage contracts.
|