Skip to content

BaseHarbor v0.4.15.1

BaseHarbor v0.4.15.1 is a focused hotfix release for defects found during real repository adoption and post-v0.4.15 lifecycle testing.

It preserves the v0.4.15 application contract while correcting the operator-visible runtime project model before productive installations exist.

Runtime Broker compatibility

A CLI rebuilt from the released source line could previously reject the matching v0.4.15 Runtime Broker solely because the Git commit SHA differed.

v0.4.15.1 keeps Git SHA as provenance but treats the versioned runtime contract as the compatibility boundary. Deterministic version mismatches now fail immediately instead of waiting through the readiness retry window.

Repository adoption and Compose behavior

Real-world Compose repositories exposed several adoption gaps.

v0.4.15.1:

  • resolves YAML anchors and merge keys during repository inspection;
  • fails explicitly on unsupported Compose include or extends inheritance instead of silently losing services;
  • refuses deterministic init when repository ambiguity has not been resolved by explicit intent;
  • detects database bootstrap mounts such as docker-entrypoint-initdb.d and stops before replacing a database if the bootstrap would otherwise be discarded;
  • automatically remaps occupied fixed host-port bindings through a BaseHarbor-owned deployment override without rewriting the repository;
  • prevents interactive TTY stdin from leaking into Compose/BuildKit progress commands and causing indefinite rebuild hangs.

Lifecycle and registry correctness

Application and installation state is more consistent after partial failures and stop/destroy operations.

  • baha app down records the observed stopped state.
  • baha app list tolerates incomplete deployment directories and reports warnings instead of failing the complete list.
  • Global baha status shows BaseHarbor-native target, control-plane and application information rather than raw Compose output.
  • Out-of-repository restore verifies that the source repository can be resolved before durable state is changed.
  • baha destroy --all removes BaseHarbor-owned Runtime Broker volumes while still preserving application-owned workload data.

Targets

The implicit local target now appears in baha target list.

Creating a new target no longer silently makes it the default unless --default is supplied, and invalid target names now explain the accepted lowercase slug rules.

MCP lifecycle

Mutating MCP operations can legitimately exceed common client request timeouts during image pulls, builds and readiness convergence.

Once a mutating lifecycle request has been accepted, BaseHarbor now keeps its convergence independent from client-request cancellation so a short client timeout does not intentionally truncate the deployment half-way through. Detached convergence is still bounded by a BaseHarbor-owned 30-minute lifecycle deadline.

Clients should still use a realistic lifecycle timeout; 300 seconds is the recommended general-purpose starting point. Read-only MCP tools may be auto-allowed while mutating tools remain approval-gated.

Initialization and Target configuration

The top-level baha init command no longer creates the obsolete global deployment: single-node configuration.

baseharbor.yaml remains the portable repository application contract. Use baha app init for application intent and baha target create for deployment destination/runtime selection. Keeping these concerns separate avoids mixing local control-plane topology into portable application configuration.

Shared OpenBao restart recovery

OpenBao recovery handling now belongs to the effective Target/shared-provider lifecycle rather than to an individual application.

After successful bootstrap, BaseHarbor persists only the absolute recovery-file path under target.openbao.recovery-file; the recovery material itself remains operator-held outside normal BaseHarbor runtime/application state. On later restarts, baha up can automatically unseal the shared OpenBao provider when that referenced file is present. An explicit --recovery-file PATH remains authoritative, while a broken persisted reference fails closed with actionable guidance.

The implicit local Target is materialized only when persistent Target state is actually required.

Docker Runtime Broker logging

A Docker-only observability regression could leave Runtime Broker stdout visible through docker logs while its provider stream never reached Alloy/Loki.

v0.4.15.1 restores the stable Runtime Broker Compose service identity broker, which restores reliable Docker syslog forwarding while retaining the consolidated application stack and all current runtime URLs/contracts.

Compatibility

Manifest v1 remains unchanged.

Docker remains Compose-based and Podman remains native Quadlet/systemd-user based. The fixed-port fallback is implemented as a deployment-local override with aligned semantics across both providers.

Operator-visible Compose identity now follows provider scope: target-wide shared components are grouped under bh-<target>-shared, while application runtime/workload and application-scoped providers use bh-<target>-<application>-<environment>. External providers remain outside BaseHarbor-owned projects. Provider state, ownership and physical resource identities remain typed and independently managed.

Security

The shared OpenBao recovery-file change persists only a filesystem path reference. Recovery keys remain outside BaseHarbor-managed application/runtime state, existing recovery files are never overwritten during bootstrap, and an explicitly persisted but unavailable recovery reference fails closed instead of silently selecting different material.

Intentionally deferred work

Stable opaque application, deployment and provider-instance identities remain planned for v0.4.19. v0.4.15.1 already preserves the required ownership boundary: shared OpenBao is Target/provider-owned and application scopes do not own the shared provider instance.

The broader Docker/Podman log-collection convergence tracked separately is also deferred; this hotfix only restores the proven stable Docker Runtime Broker service identity.

For the complete technical list, see the v0.4.15.1 changelog.