Skip to content

BaseHarbor v0.4.1

BaseHarbor v0.4.1 is a small architectural release with a practical goal: make backend capabilities replaceable later without forcing applications to change how they describe or consume them today.

For existing users, the important part is simple: your Manifest v1 and current Compose workflow stay the same. PostgreSQL, Valkey and OpenBao continue to work through the existing proven runtime paths.

What changes under the hood is the foundation BaseHarbor will use for later provider choices, managed services, Kubernetes and OpenShift.

Why this release matters

Until now, BaseHarbor already separated application intent from much of the Compose implementation, but the individual backend capabilities still needed a common domain model.

v0.4.1 introduces that common language:

application requirement
        ↓
logical capability
        ↓
provider
        ↓
logical resource
        ↓
workload binding
        ↓
verification

For example:

database.sql    -> PostgreSQL
cache.key-value -> Valkey
secrets         -> OpenBao

Applications still use normal environment variables, files and native protocols. They do not need a BaseHarbor SDK and do not need to know provider-internal identities.

Added

  • A shared model for capabilities, providers, logical resources and workload bindings.
  • Fail-closed capability/provider negotiation before provisioning starts.
  • A reusable lifecycle for resolve -> preflight -> apply -> bind -> verify.
  • Machine-readable lifecycle status and diagnostics that can later be reused by the CLI, Web UI/API and Operator instead of implementing separate behavior.
  • Protected runtime metadata describing which logical capability is bound to which provider and workload.

Changed

  • PostgreSQL, Valkey and OpenBao requirements now pass through the shared capability model.
  • BaseHarbor validates provider compatibility before mutation.
  • All planned capability preflights complete before the reusable lifecycle permits provisioning.
  • The existing Compose provisioning and protocol-level verification paths remain authoritative; v0.4.1 does not replace them with a second framework.

Security

  • Unsupported capability/provider combinations fail before mutation rather than silently falling back.
  • Secret values and credential-bearing provider configuration remain outside the portable capability model and machine-readable diagnostics.
  • Existing OpenBao isolation and runtime credential boundaries are unchanged.

Deprecated

No public baha command or Manifest v1 field is deprecated in v0.4.1.

Removed

Nothing from the supported v0.4.0 CLI, Manifest v1 or Compose workflow is removed.

Compatibility & upgrade notes

Existing v0.4.0 repositories require no manifest migration.

After upgrading BaseHarbor, applications continue to use the same:

  • baseharbor.yaml;
  • Compose-based developer workflow;
  • PostgreSQL/Valkey environment variables and file bindings;
  • managed-secret workflow;
  • backup/restore and readiness behavior.

v0.4.1 deliberately does not add provider registry/ownership policy, Kubernetes/OpenShift implementations, cloud providers or a new generic public capability manifest. Those are separate roadmap steps so this release stays small, understandable and compatible.

For the detailed technical history, see CHANGELOG.md.