Skip to content

BaseHarbor v0.4.19

BaseHarbor v0.4.19 completes the remaining service and provider foundations planned before the v0.5 contract freeze.

The release adds portable messaging, durable key-value and document-database capabilities, first-class External/BYO provider onboarding, organization-wide platform configuration, and clearer Runtime/Delivery provider boundaries.

New portable service capabilities

v0.4.19 adds three provider-neutral service families:

  • database.key-value/v1
  • database.document/v1
  • messaging.queue/v1
  • messaging.pubsub/v1
  • messaging.stream/v1

The reference providers are:

  • Valkey for durable key-value data;
  • MongoDB for document databases;
  • RabbitMQ for queue, pub/sub and stream messaging.

Application intent describes the capability an application needs, not the implementation product.

A durable key-value database is now also explicitly distinct from cache.key-value: both may use Valkey, but they have different durability, lifecycle and recovery semantics.

External and BYO providers

Existing enterprise infrastructure can now be registered and consumed through the normal BaseHarbor provider model without making BaseHarbor the owner of that infrastructure.

The External/BYO flow supports provider registration, inspection, verification and removal while preserving the ownership boundary:

BaseHarbor manages the binding
    !=
BaseHarbor owns the external service

External placement is available for the supported provider families, including PostgreSQL, Valkey, RabbitMQ and MongoDB.

TLS onboarding supports system trust, custom CA material, SAN/wildcard certificates, mTLS references and directory-based certificate discovery. Certificate and private-key material remain deployment/operator state and never become portable Application Intent.

Organization and platform configuration

Platform teams can now distribute organization-wide BaseHarbor defaults without changing each application's portable contract.

Organization configuration can provide reusable references for:

  • Stack Profiles;
  • Targets;
  • provider defaults;
  • External/BYO providers;
  • trust and certificate material;
  • policy references.

Configuration can be distributed from local/system sources, Git or OCI artifacts with immutable revision/digest resolution and provenance.

Developer workflows continue to use the normal BaseHarbor commands; organization defaults simply reduce repeated choices where resolution is unambiguous.

Provider management surfaces

RabbitMQ, durable Valkey and MongoDB now participate in the same optional management-surface model as existing providers.

Management UIs remain operator/developer surfaces, not application capabilities. They use canonical HTTPS development access and preserve application/shared/external ownership semantics.

Provider and contract consistency

The public provider surface now includes the new v0.4.19 capability families across:

  • provider descriptors;
  • Provider SDK/scaffolding;
  • versioned service schemas;
  • Development Adapters;
  • repository inspection;
  • CLI, JSON and MCP surfaces.

This keeps third-party provider implementations aligned with the same capability model used by bundled providers.

Runtime and delivery boundaries

v0.4.19 freezes a smaller provider-neutral Runtime boundary that does not require future Kubernetes/OpenShift providers to imitate Docker, Compose or Podman mechanics.

Source/build resolution ends before the Runtime boundary. Runtime providers consume resolved OCI workload artifacts and expose portable lifecycle, observation, readiness, logs, execution and ownership semantics.

Delivery is a separate provider axis with explicit direct versus delegated reconciliation ownership. This keeps future GitOps implementations such as Argo CD or Flux out of portable Application Intent.

The Kubernetes pre-freeze proof was used to verify these boundaries without introducing Kubernetes-specific fields into the portable BaseHarbor contracts.

Final stabilization

The release-candidate hardening pass also closes the main developer-journey failures found during v0.4.19 verification:

  • non-interactive CLI and MCP memory-approval semantics now stay consistent and typed;
  • PTY-driven required-secret entry preserves buffered input across multiple prompts;
  • workload failures retain bounded secret-safe diagnostics before cleanup and failed rebuild candidates cannot poison later source-change detection;
  • HTTPS workload contracts fail before mutation when required exposure intent is missing;
  • nested companion applications can be initialized inside an already adopted repository tree;
  • generated Go and Python greenfield workloads start with complete dependency/readiness behavior;
  • destroy and restore no longer leave deployment/provider state that produces empty residue, phantom reconciliation or missing development routes;
  • workspace bootstrap errors and development management credentials are discoverable through normal BaseHarbor UX;
  • the Target/environment development username remains configurable, with developer only as the default.

Security

v0.4.19 keeps portable intent separate from provider credentials, trust material and runtime ownership state. External/BYO onboarding is binding-management only: BaseHarbor does not claim ownership of external infrastructure, and removal must not destroy it. Shared-provider administration credentials remain separate from application credentials, normal status/doctor/evidence output remains secret-safe, and destructive operations continue to fail closed on ambiguous ownership or unsupported placement.

Compatibility

Docker and rootless Podman remain the reference runtimes for v0.4.19.

Kubernetes/OpenShift production support is not introduced by this release. v0.4.19 establishes the contracts required so those providers can be added later without redesigning application or capability semantics.

Intentionally deferred

  • Kubernetes and OpenShift production Runtime Providers remain future releases; v0.4.19 freezes the provider-neutral contracts they will consume.
  • Delivery-provider implementations such as Argo CD or Flux are not introduced by this release.
  • Broader dynamic provider/plugin loading remains outside the v0.4.19 release boundary.