Deployment overview

The deployment pattern is simple: place trustplane-adapter in front of an existing API and let it verify every request before forwarding. The upstream can stay unchanged while the adapter enforces passports, transcript-v1 request proof, route policy, replay protection, source rules, signer class, bundle freshness, and stable audit outcomes.

Artifact boundary

Artifact	Owns
Runtime binaries	CLI, adapter, broker, local demos, and acceptance checks.
Deployment package	Helm chart shape, example values, and deployment safety rails.
Public docs	Product, adopter, deployment, and reference guidance.

Deployment examples explain the shape and safety rails. They are not a live operations credential store and do not imply that public release artifacts are already published.

What an adapter deployment needs

• An adapter process or container.
• A protected upstream URL reachable only through the intended boundary.
• Signed trust material containing allowed issuer keys.
• A signed trustplane-bundle-v1 policy bundle containing routes, allowed sources, signer-class requirements, freshness policy, and optional provenance/context constraints.
• Replay storage appropriate for the replica count. A single local/demo adapter can use memory; multi-replica deployments need a shared replay store.
• Read-only bundle mounts and a way to refresh those files without rebuilding the adapter image.

Operating principles

• Adapter is stable infrastructure. New clients and route policy changes are bundle publishes, not image rebuilds.
• Signed bundles are the production-style default. Unsigned bundle skeletons are local development artifacts only.
• Replay state must match topology. Multi-replica adapters need a shared replay store so a consumed jti is consumed everywhere.
• The upstream boundary matters. Upstreams may trust forwarded X-TrustPlane-* headers only when untrusted callers cannot bypass the adapter or forge adapter-to-upstream traffic.
• No committed secrets. Credentials, signing keys, live bundle contents, and signed request logs do not belong in this repo or in public docs.

Security posture

Recommended defaults:

• Run as a non-root user.
• Use a read-only root filesystem where the platform supports it.
• Drop unnecessary capabilities.
• Mount trust and policy bundles read-only.
• Keep the adapter as the only network path to the protected upstream.
• Use TLS, ingress, WAF, or gateway controls appropriate to the environment.

Current public posture

TrustPlane Auth is useful locally today and can be run as an adapter with reviewed signed bundles. The public docs intentionally avoid provider-specific live cluster details. Treat the deployment pages as a foundation for safe review and implementation planning, not as a claim that this docs branch has published a hosted service.

Where to go

• The Helm chart - values, templates, and safety rails.
• Example deployment - provider-neutral deployment flow.
• Bundle refresh & key lifecycle - add or remove trust material without rebuilding the adapter image.
• Install & artifacts - current release artifact posture.