Skip to content

BaseHarbor v0.4.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 18 Sep 18:05
· 765 commits to main since this release
v0.4.2
c98f5f5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

BaseHarbor v0.4.2

BaseHarbor v0.4.2 separates an application's logical resource from the provider instance that happens to serve it.

That distinction lets BaseHarbor reuse infrastructure where sharing is sensible, keep dedicated infrastructure isolated where it matters, and adopt existing external services without pretending BaseHarbor owns them.

The developer workflow stays the same: no Manifest v1 migration is required.

Added

BaseHarbor now understands three provider scopes:

  • shared — one BaseHarbor-managed provider can serve multiple applications;
  • application-scoped — a provider belongs to one application and cannot cross that ownership boundary;
  • external — an existing/BYO provider can satisfy a logical resource while its lifecycle stays outside BaseHarbor.

The provider registry is persisted in protected BaseHarbor state and records logical resource-to-provider-instance bindings plus explicit lifecycle ownership.

Changed

The current stack now maps naturally to the registry:

OpenBao              -> shared
PostgreSQL instances -> application-scoped
Valkey instances     -> application-scoped

A second application can reuse the same compatible shared provider without BaseHarbor accidentally provisioning a duplicate. Dedicated providers remain isolated to their owning application.

Existing v0.4.1 applications are adopted automatically after the next successful baha app apply or baha app up.

Destroying an application removes its bindings and BaseHarbor-owned application-scoped provider records while shared and external provider instances remain.

Security

Provider registry state is written atomically with owner-only permissions and read/modify/write updates are serialized so concurrent BaseHarbor operations cannot silently overwrite each other.

Application-scoped providers fail closed on cross-application binding attempts. Corrupt, duplicate or ambiguous registry state is rejected.

External provider entries use non-secret references only; credentials and secret-bearing connection data remain outside the registry. BaseHarbor never treats an external provider as lifecycle-owned.

Deprecated

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

Removed

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

Compatibility & upgrade notes

No baseharbor.yaml migration is required.

Provider placement remains deployment/operator state and is intentionally not added to portable application intent.

v0.4.2 does not yet add a public provider-selection syntax, replace existing Compose provisioning, or implement Kubernetes/OpenShift/cloud providers. Those remain separate milestones so this release stays focused and compatible.

The practical benefit is architectural but concrete: later shared observability, dedicated databases, customer-managed services and cloud providers can be introduced without changing what the application says it needs.

For detailed technical history, see CHANGELOG.md.

Assets 5
Loading