Skip to content

BaseHarbor v0.4.16

BaseHarbor v0.4.16 completes the recovery and audit/evidence track planned for the final v0.4 productization line.

Selectable application recovery units

Backup is now modeled as one typed application recovery unit instead of a fixed SQL-and-secrets snapshot.

Supported application-owned recovery state includes:

  • application metadata;
  • managed SQL data;
  • the application-owned OpenBao secret scope;
  • managed S3 object contents;
  • BaseHarbor-owned repository workload named volumes;
  • selectable application log history;
  • application/runtime identity reconstruction.

Interactive backup and automation use the same state classes. Guided backup lets an operator choose supported recovery classes, while scripts use --include-state and --exclude-state.

Restore validates the complete recovery manifest and selected payloads before destructive mutation. Success is reported only after restored state, runtime identities, workload readiness and Doctor verification pass.

External named volumes, bind mounts and external data stores remain outside BaseHarbor ownership and are represented explicitly rather than silently copied.

Metrics and trace history are intentionally still unsupported recovery contributors because BaseHarbor does not yet provide a safe application-scoped restore path for those histories.

Audit and evidence v1

v0.4.16 adds a shared evidence model built from the same plan, policy, status, doctor, recovery and lifecycle semantics already used by BaseHarbor.

Human operators can inspect it with:

baha app evidence

Automation can export the deterministic machine representation with:

baha app evidence -o json

Agents receive the same typed result through the read-only MCP operation:

baseharbor.evidence

The bundle separates desired state, enforced policy, observed state, verified results, explicit exceptions, unsupported controls, recovery evidence and bounded lifecycle audit history.

Meaningful completed lifecycle operations record secret-safe Target-local audit events. The export is deterministically ordered and includes a SHA-256 digest as tamper evidence.

The digest is not a digital signature, remote attestation or compliance certification.

Real-world acceptance hardening

The final v0.4.16 candidate also includes fixes found while adopting public Compose applications rather than only the BaseHarbor demo:

  • deterministic init refuses to silently omit an existing repository workload;
  • effective Compose configuration changes, including interpolated .env values, participate in convergence and READY state;
  • managed SQL/cache connectivity is projected through Service Binding 1.1 with workload-native endpoints and verified TLS trust;
  • secondary database/cache aliases that still point at a replaced repository service are safely rewired when unambiguous and fail closed otherwise;
  • failed convergence remains addressable through persisted deployment lifecycle state, while older incomplete deployments can be recovered by name;
  • destroy reclaims only ownership-proven volumes that belonged exclusively to replaced repository database/cache services and preserves shared, external or unknown workload data.

The fixed Compose host-port fallback introduced in v0.4.15.1 remains covered by the v0.4.16 regression suite: occupied fixed HOST:CONTAINER bindings continue to use a deployment-local override without modifying repository source.

Security and ownership

Recovery and evidence preserve the existing BaseHarbor ownership model.

  • External volumes, bind mounts and operator-owned data are never silently adopted into BaseHarbor recovery ownership.
  • Application/runtime leaf identities are reconstructed; Target-wide OpenBao PKI private keys are not copied into an application archive.
  • Audit history is bounded and owner-only.
  • Evidence excludes secret values, tokens, access keys, private keys, credential-bearing URLs, prompts and agent/model reasoning.
  • CLI and MCP use the same semantic collectors and do not expose provider-native or generic shell execution.

Compatibility

Manifest v1 remains unchanged.

Existing recovery archives remain readable through the legacy recovery-manifest fallback. New v0.4.16 archives carry the typed recovery manifest and contributor semantics.

Docker Compose and Podman/Quadlet use the same logical recovery contract. Recovery discovery accepts both normalized Compose volume objects and short-syntax mounts, while physical runtime resource names remain deployment detail and are not portable application identity.

No SIEM- or compliance-vendor-specific integration is introduced; JSON output is the generic evidence export boundary.

For the complete technical list, see the v0.4.16 changelog and release audit.