BaseHarbor v0.4.10

BaseHarbor v0.4.10

v0.4.10 completes the first generic observability path in BaseHarbor and adds Tempo as the trace-storage reference provider without turning observability products into application requirements.

The release is deliberately about platform architecture, not adding another bundle of infrastructure products.

Provider observability without core product branches

Provider Integration Contract v1 can now describe provider-owned observability signals.

A running provider may register a safe OpenMetrics endpoint with BaseHarbor. The metrics platform consumes those registrations generically, so Prometheus does not need product-specific branches for Loki, Tempo, the OpenTelemetry Collector or future conforming providers.

Collection remains policy-controlled. A declaration says that a signal exists; it does not automatically authorize collection.

Shared Prometheus instances filter application-scoped provider signals by the applications registered in that exact sharing boundary. Provider sharing therefore does not create cross-application observability access.

The first managed providers using this mechanism are:

• OpenTelemetry Collector;
• Loki;
• Tempo.

Providers that do not expose a suitable metrics endpoint are unaffected.

Trace storage remains separate from OTLP transport

Applications continue to describe trace export through telemetry.otlp/v1. They do not request Tempo.

When deployment policy enables managed trace retention:

export BASEHARBOR_TRACES_ENABLED=true
baha app up

BaseHarbor:

1. provisions/reuses the shared Tempo reference provider;
2. connects the managed OpenTelemetry Collector to Tempo over a BaseHarbor-managed provider network;
3. exports the normal BaseHarbor OTLP verification trace through the Collector;
4. queries that same trace from Tempo;
5. reports the trace path ready only after real ingestion is proven.

Tempo 3.0.2 is the first Compose reference implementation of the provider-neutral traces/v1 platform contract.

Deliberately narrow placement support

v0.4.10 does not pretend to support isolation modes that the current Compose path cannot safely realize.

The Tempo reference adapter supports the default shared placement. Application-scoped, external and named-sharing-boundary Tempo placement are rejected before mutation.

This is intentional fail-closed behavior. Future providers/adapters may implement additional placements through the same contract without changing application intent.

Metrics behavior

When metrics collection is enabled, BaseHarbor now collects:

• declared application metrics/v1 sources;
• policy-authorized application-provider metrics;
• policy-authorized platform-provider metrics.

Provider targets are reconciled automatically and verified with a real Prometheus up=1 sample.

Prometheus joins only the provider networks required by the selected registrations. This collector reachability does not grant workloads or applications access to those provider networks.

Compatibility

Manifest v1 remains unchanged.

Existing application metrics, runtime-created metrics sources, centralized logs and OTLP transport remain compatible. No Tempo, Prometheus, Loki or provider-observability product detail is added to portable application intent.

Trace retention is opt-in deployment policy. Applications that already export OTLP traces continue to work exactly as before when managed trace storage is disabled.

Security

• Tempo runs as non-root.
• Its root filesystem is read-only.
• All Linux capabilities are dropped.
• no-new-privileges is enabled.
• Only explicit persistent storage and tmpfs paths are writable.
• The host-facing Tempo API is bound to loopback.
• Shared metrics collection filters provider signals by placement, sharing boundary and authorized application registrations.
• Provider observability registry state contains no credentials or secret values.
• Unsupported trace-provider placements fail before mutation.

Intentionally deferred

• Grafana is not part of v0.4.10 and is now post-v0.5 ecosystem work.
• Tempo application-scoped/external/named-boundary adapters are not implemented.
• Existing PostgreSQL, Valkey, OpenBao, SeaweedFS and Caddy providers are not given synthetic exporters merely to make them appear in Prometheus. They will advertise metrics only when their provider implementation exposes a safe supported signal.
• Kubernetes/OpenShift/cloud runtimes remain later runtime tracks.
• Broader policy/evidence work is scheduled for the new productized v0.4.13-v0.4.15 roadmap.