BaseHarbor v0.4.6

BaseHarbor v0.4.6

BaseHarbor v0.4.6 adds provider-neutral S3-compatible object storage as the next real capability behind the shared provider contract.

Why this matters

Applications often need object storage long before they need a full observability or AI/RAG stack. BaseHarbor now lets an application request logical S3 buckets without coupling the application contract to SeaweedFS, Ceph, AWS or another storage product.

The same separation used for databases, secrets and managed exposure now applies to object storage:

application intent
  object-storage.s3/v1
        |
        v
provider boundary
        |
        +-- SeaweedFS today
        +-- Ceph RGW / AWS S3 / other conforming providers later

Added

• Versioned object-storage.s3/v1 Capability Specification.
• Manifest v1 object-storage declarations with one or multiple logical buckets.
• --s3 and repeatable --s3-bucket NAME application-init/create paths.
• SeaweedFS 4.47 as the first lazy shared Compose reference provider.
• Bucket-scoped SeaweedFS IAM identities and credentials.
• Provider-neutral secure-binding/v1 metadata for S3 access.
• Standard S3/AWS-compatible host and workload bindings.
• Authenticated AWS SigV4 Put/Get readiness in apply, up, status and doctor.
• Provider-registry ownership for the shared SeaweedFS instance and application-owned logical buckets.
• Real Docker/Compose acceptance coverage for the S3 lifecycle.

Changed

• Object-storage provider lifecycle now uses the shared plan/preflight/provision/bind/verify path.
• SeaweedFS administrative IAM commands are delivered through stdin so per-bucket credentials never appear in process arguments or runtime error messages.
• Application backup/restore fails closed while S3 object contents are outside the recovery unit.

Application contract

A repository can request object storage without naming a product:

services:
  object_storage:
    buckets:
      attachments: {}
      exports: {}

or:

baha app init mailflow \
  --s3-bucket attachments \
  --s3-bucket exports

Provider-native bucket names, IAM identities, ports, storage topology and SeaweedFS configuration remain protected provider/deployment state.

Application-facing bindings

For an unambiguous preferred bucket BaseHarbor publishes normal S3/AWS configuration such as:

S3_ENDPOINT
S3_BUCKET
S3_REGION
AWS_ENDPOINT_URL
AWS_REGION
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Named buckets additionally receive S3_<NAME>_* variables and protected file bindings.

Repository workloads use the internal provider endpoint through a BaseHarbor-owned object-storage integration network. Host-side processes use a loopback-only endpoint. Applications need no BaseHarbor SDK or runtime login.

Security

• Each logical bucket receives separate credentials scoped to that bucket.
• SeaweedFS IAM is explicitly enabled.
• BaseHarbor does not persist a global S3 superuser credential for the reference provider.
• S3 credential files are owner-only.
• baha app env masks S3 access-key and secret-key values by default.
• Plaintext credentials do not enter portable capability metadata, provider-registry records or normal diagnostics.
• A shared provider process does not imply shared bucket authorization.

Readiness and lifecycle

Success is not based on a running SeaweedFS container. BaseHarbor signs a real S3 request and verifies a Put/Get flow with the application's bucket-scoped credentials.

baha app down preserves the shared provider and bucket data. baha app destroy --yes removes only the application's managed buckets/identities and state. The shared provider remains available for other applications and is removed only by global baha destroy --yes after application bindings are gone.

Recovery boundary

Object contents are not yet part of the BaseHarbor encrypted application recovery unit. v0.4.6 therefore fails closed for baha app backup and baha app restore when managed object storage is declared. BaseHarbor will not present an incomplete S3 recovery as successful backup/restore.

Deprecated

Nothing.

Removed

Nothing.

Compatibility & upgrade notes

• Manifest version remains 1.
• Existing manifests require no migration.
• PostgreSQL, Valkey, OpenBao, secure bindings, managed exposure and existing Compose workflows remain compatible.
• Object storage is additive and opt-in; no SeaweedFS runtime is created unless an application explicitly requests S3.
• SeaweedFS is a reference implementation, not application identity.

Provider replacement

The capability lifecycle, Provider Integration Contract v1, provider registry and conformance tests prove that the same logical S3 request can be satisfied by another conforming driver without changing application intent.

The current public v0.4.6 workflow selects the built-in SeaweedFS reference implementation for managed Compose object storage. General dynamic external-provider loading/selection remains separate platform work; no product-specific fields are added to the application contract in anticipation of it.

Intentionally deferred

• Generic dynamic external-provider loading and public provider-selection policy.
• Ceph RGW, AWS S3 and cloud/provider adapters as shipped BaseHarbor provider implementations.
• Object-storage data capture/restore inside BaseHarbor application recovery units.
• Application-requested replication/topology/tiering/versioning policy.
• Public object-storage endpoint exposure.
• Kubernetes/OpenShift object-storage runtime/provider mappings.