Skip to content

BaseHarbor v0.4.15

BaseHarbor v0.4.15 is a major step toward the v0.5 contract freeze. It expands BaseHarbor from a strong local developer platform into a more complete, agent-native and runtime-neutral application lifecycle while keeping portable application intent independent from concrete infrastructure products.

Full MCP lifecycle

The MCP/JSON interface is no longer limited to inspection.

Agents can now use the supported BaseHarbor lifecycle through the same semantic core as the CLI, including:

inspect -> plan -> apply -> status -> doctor -> observe -> update -> repair -> backup -> restore -> destroy

Policy, ownership, reconciliation, verification and approval requirements remain enforced regardless of whether BaseHarbor is operated by a human or an agent.

No generic shell, Docker, Compose or Podman execution interface is exposed.

Native Podman with Quadlets

Docker continues to use Docker Compose.

Podman now uses native rootless Quadlets managed through systemd --user instead of relying on podman-compose.

The same BaseHarbor application and provider semantics are preserved across both runtimes, while Podman now follows its native runtime model more closely.

Secure service access

Managed service access now follows a common TLS and authentication model across environments.

BaseHarbor supports managed local PKI as well as external/BYOC PKI while keeping trust, credentials and transport details out of portable application intent.

Applications continue to consume standard URLs, environment variables and file bindings while BaseHarbor manages the deployment-side security model.

Complete metrics, logs and traces

The observability model has been completed across:

  • metrics;
  • logs;
  • traces.

Application workloads, managed providers, Runtime Broker and Runtime Executor now participate in the same provider-neutral observability model.

Prometheus, Loki, Tempo and OpenTelemetry remain reference implementations behind portable contracts rather than becoming part of the application API.

CLI Targets and installation-wide lifecycle

v0.4.15 introduces first-class Targets as a new deployment dimension.

A deployment is now identified by:

target + application + environment

This allows the same application and environment to exist independently across different Docker or Podman Targets while BaseHarbor keeps runtime state, providers, networks, volumes and ownership state isolated.

Targets are available consistently through the CLI, shell integration, JSON and MCP interfaces and establish the runtime boundary needed for future Kubernetes and OpenShift support.

The Target model also enables installation-wide cleanup across all known Targets:

baha destroy --all

Cleanup remains ownership-safe: application source repositories and foreign or external application-owned resources are preserved.

Smarter init and repository adoption

BaseHarbor is better at understanding existing repositories before asking the developer to describe them manually.

Repository inspection can distinguish application workloads from replaceable infrastructure, detect supported capabilities and guide adoption without silently inventing intent when a repository is ambiguous.

Guided init now includes clearer capability selection, improved secret handling, deterministic workload selection and more actionable failures.

The application model also became more provider-neutral during this work: generic service families such as sql and cache are used instead of product-specific application intent, while standards-based service bindings remain the integration surface for workloads.

Compatibility

Manifest v1 remains the compatibility contract.

Docker remains Compose-based. Supported Podman execution now uses native Quadlets.

Kubernetes and OpenShift Targets fit the new Target architecture, but runtime execution for them is intentionally deferred to a later release.

For the complete technical change list, compatibility details and security notes, see the v0.4.15 changelog.