Skip to content

BaseHarbor v0.4.0

BaseHarbor v0.4.0 prepares the platform for the next step beyond Compose without breaking the existing v0.3 developer workflow.

Applications keep their current Manifest v1 baseharbor.yaml. Internally, BaseHarbor now separates portable application requirements from runtime selection, provider implementation and deployment-specific inputs. This is the foundation for future replaceable backend providers, Kubernetes and OpenShift support.

Highlights

  • Same application contract, cleaner architecture: Manifest v1 stays compatible while portable intent is normalized into a provider-neutral PortableContract.
  • Runtime provider boundary: Compose remains the complete runtime today, but runtime selection and required capabilities are now explicit and fail-closed.
  • Smarter setup: baha app init and repository-aware baha up resolve only missing deployment values instead of duplicating prompt logic.
  • Automation-friendly inputs: non-secret deployment values can be supplied with --input NAME=VALUE.

Added

  • Provider-neutral PortableContract for logical SQL, key/value and secret requirements.
  • Runtime-provider identity, profile state and capability negotiation.
  • Central guards that stop unsupported providers from falling through into Compose-specific operations.
  • Declarative input resolution with defaults, generated values, external values and conditional required-if rules.
  • baha app init --input NAME=VALUE for explicit non-secret automation input.
  • Contract-versioning rules for future schema evolution.

Changed

  • Manifest v1 is now explicitly the public compatibility surface; PortableContract is the internal provider-neutral application view.
  • Application requirements, runtime-provider selection and backend/capability-provider selection are separate concerns.
  • Repository runtime operations verify the selected provider and required runtime capabilities before mutation.
  • Interactive setup asks only for unresolved deployment values; existing protected state is reused.
  • Compose remains first-class and fully supported, but is no longer treated as the permanent conceptual application API.

Security

  • Unsupported runtime providers or missing capabilities fail before mutation instead of silently degrading to Compose.
  • Secret input values are redacted when rendered and excluded from generic persistable resolver output.
  • Runtime/provider state stays in protected deployment state rather than committed application configuration.

Deprecated

No public baha command or Manifest v1 field is deprecated in v0.4.0.

Compose-oriented Manifest v1 fields remain supported compatibility inputs, but they should no longer be considered the long-term provider-neutral model.

Removed

Nothing from the supported v0.3 CLI or Manifest v1 workflow has been removed.

Compatibility & upgrade notes

Existing v0.3 repositories should continue to work without rewriting baseharbor.yaml.

Legacy deployment state without explicit runtime-provider metadata safely defaults to Compose.

There is no Kubernetes or OpenShift runtime implementation in v0.4.0. Those remain future releases; v0.4 provides the contract and provider boundaries they will use.

For an existing Compose user, the intended upgrade is simply:

v0.3 application
      ↓
upgrade BaseHarbor
      ↓
same manifest
same Compose workflow
new provider-neutral internals

For the full technical change history, see CHANGELOG.md.