BaseHarbor v0.4.23

Released on 2026-10-08. Release umbrella: #571; implementation: #809.

Core installation and first application

BaseHarbor Core provides SQL, Secrets and Identity. The reference providers are PostgreSQL, OpenBao and Keycloak. The Web Console is optional.

Core setup does not require an Application or a repository. It verifies the three capabilities and records an authoritative installation identity and readiness state. A retry reconciles owned resources and preserves that identity; foreign or ambiguous state is refused. Partial failures retain their bootstrap stage for recovery.

When the first application needs a Core, guided setup offers to provision it and continues the original operation after readiness verification. Non-interactive requests return an explicit bootstrap requirement unless automatic setup was requested. CLI, JSON, MCP and protected HTTP use the shared bootstrap semantics.

The development/deployment machine question changes defaults. Development defaults support local repositories and workspaces; deployment defaults require explicit source/workspace selection. Ordinary safe local development does not require an interactive login.

Security and placement

Protected credentials and TLS remain part of the Core contract. Core capabilities are mandatory; provider placement may be shared or application-isolated. Additional isolation can add provider instances and resource consumption.

An optional Console connects to one selected Core within the same installation and security boundary. Same-origin HTTPS is the default topology. Browser-origin and destination checks prevent credentials from being forwarded to a foreign Core. Application Identity reconciliation cannot replace installation Identity resources.

Application operations keep Core-managed secrets, service PKI and runtime-permission brokers bound to the selected installation, independently of workload placement. Execution revalidates that Core binding and refuses changed or unavailable configuration before native workload inspection or mutation. Remote selections never fall back implicitly to a local Core.

Generated provider TLS bind files keep the permissions required by their unprivileged native service beneath protected staging directories. Runtime environments remain owner-only. Immutable project verification detects altered file permissions before execution; ordinary destroy retains persistent data, while an explicit owned reset can remove it. Actual remote Application qualification remains required.

Ordinary Podman destroy/reapply retains and reuses the same owned provider data volume. Managed unit removal rechecks native ownership before stopping a service; an old own unit receipt cannot authorize a resource replaced with foreign labels.

The remote Quadlet project adapter publishes the complete graph before activation, starts container dependencies before their dependents, and reverses that order for destruction. Cyclic dependencies are rejected before publication. These project mechanics still require actual remote Application qualification.

Core-managed init services retain native completion evidence. Core verifies successful completion before starting a dependent application; failed or unstarted init services block activation. These managed units are excluded from automatic node startup so a reboot cannot bypass Core verification.

Managed provider publication requires the exact immutable project receipt to be persisted by Core before activation. A failed persistence step leaves no executable handle and does not automatically replay publication. Owned Podman network teardown removes only the exact network without force, preserving live consumers. Explicit provider data reset verifies volume absence and reconciles an explicit retry after ordinary teardown. The focused native provider proof does not replace the complete remote Application journey.

Resource output distinguishes planning estimates from measured observations. No universal Core memory minimum is claimed. Qualification samples the complete PostgreSQL/OpenBao/Keycloak topology, recording stabilized idle usage, sampled startup/convergence peaks, simultaneous totals, provider images and placement. The Core resource observations record the qualified Docker reference topology and its measurement limits.

Remote memory preflight uses fresh available-RAM/swap evidence from the selected authenticated execution node. Core-host RAM and runtime-info totals cannot substitute for node capacity; exhausted RAM is refused even without a reliable workload estimate. This projection does not measure PSI or VM/cgroup limits and does not establish complete remote Application qualification.

Managed trust rotation

The protected HTTP projection can request the same Core credential and service CA rotation used by CLI/MCP for an explicitly selected installation. The connected Console asks for confirmation; recovery material remains with Core. Rotation returns only verified readiness flags. Interrupted observation must be inspected before retrying, and does not trigger automatic replay. Browser rotation qualification against the final release candidate remains required.

v0.4.22 regression fixes

Identity startup authenticates the first Keycloak member before additional members join, preventing concurrent initial database migrations. Core readiness also tolerates transient native authentication-server errors; invalid credentials and other client denials still fail closed.

Interactive terminals preserve early input and terminal protocol replies. Log observations deliver small output chunks promptly, including when following an otherwise idle container. Execution observations preserve idle HTTPS transport during provider setup; keepalive comments do not report progress or extend authentication deadlines. Application repair retains its selected environment. Authenticated operator requests preserve tenant membership resolution across reused database connections without weakening row-level isolation or allowing unscoped writes.

Application overview now consumes the canonical status observations, including managed providers. Backup restores runtime-permission brokers using Core runtime context and attempts bounded recovery after capture cancellation. Closed or non-terminal secret input returns an actionable missing-secret error.

Generated Compose and source consume matching runtime bindings. Go image builds retain the module state produced by tidy, Next.js checks runtime bindings during requests, and Quarkus executes packaging through Maven. Generated workloads are recognized independently of valid Compose YAML indentation. Fresh Core setup preserves old recovery files and allocates a fresh default output; operator-selected paths remain protected against overwriting.

The focused runtime regressions and fresh native template builds are required before these fixes are considered release-qualified (#811–#815, #526).

Public companion implementations

The optional BaseHarbor Console and BaseHarbor Node Connector are public companion repositories. They remain consumers of Core-owned contracts, not independent control planes.

The Console has qualified native journeys for authenticated Core/OIDC admission, local application plan/apply/status/doctor/repair/destroy, first-application Core setup, protected trust rotation, terminal and live log streaming. Qualification against the final pinned release candidate remains required. These local journeys do not establish remote application support.

The Node Connector has native Docker/Podman evidence for enrolled, authenticated provider publication, TLS probes, immutable repair, owned cleanup and preservation of foreign resources. End-to-end remote Application support still requires exact-ref Core -> Connector -> runtime qualification. Kubernetes/OpenShift normally use their native authenticated APIs and do not require the Connector.

Repository-local green checks are necessary but do not substitute for the pinned cross-repository evidence required by the v0.4.23 release requirements.

Remote status and overview inspect the protected deployment binding and live owned Node inventory. Missing local files cannot establish remote absence. Provider health alone leaves complete application readiness unverified.

Read-only Core Identity reconciliation now covers the bounded native Keycloak JDBC reconnection window after HA database convergence. Mutations and rejected authentication remain fail-closed.

The Console release producer can qualify the exact Core candidate from a controlled immutable-SHA integration branch, with the Demo pin read from that Core. The six locked public contracts still require byte-for-byte equality. This avoids recursive source pins without weakening required qualification.

Release qualification

The release requirements retain the released acceptance baseline and require the new integration proofs. Source checks do not substitute for actual Docker/Podman, browser, Connector or remote application journeys. Missing or failed evidence prevents approval.

The final release notes will include the remaining integration behavior after its implementation and qualification are complete. Final human CLI consolidation remains #610/#611 scope.

• Keycloak bootstrap uses the active administrator after credential rotation. MongoDB treats credentials beginning with a dash as values in health checks, HA probes and rotation.

• OIDC discovery retries transient server failures within a bounded identity convergence window; access denials remain blocking.

• Core realm reconciliation reads back state and rechecks ownership before resuming after transient server failures.