Skip to content

Adoption path

You can run TrustPlane Auth on its own indefinitely — but as deployments multiply, manual bundle signing and lifecycle work starts to hurt. This page explains the TrustPlane platform operating model — control centrally, enforce locally — as an adoption sequence: start with TrustPlane Auth, the free-to-use enforcement plane that protects requests locally, and add TrustPlane Control, the governance plane, when the fleet grows and central governance becomes valuable. Auth and Control are two distinct components designed to be used together.

TrustPlane Auth is the enforcement plane on the customer side. It is a deployable runtime that protects requests locally at adapters, gateways, sidecars, middleware, and services. Auth is free to use and remains useful by itself for local development, offline verification, signed local bundles, and manually operated deployments.

TrustPlane Control is the governance plane and the enterprise offering, delivered as managed SaaS — the cockpit for enrollment, policy releases, revocation, fleet visibility, audit, and operator access. It manages lifecycle, distribution, evidence, approvals, and status for many Auth deployments across clusters, regions, environments, edge nodes, teams, and business units. Control is never a hot-path runtime dependency and is not paired one-to-one with a single Auth instance. For organizations that need the governance plane inside their own environment, TrustPlane Edge is the self-hosted deployment of Control, with advanced, tailored capabilities.

  1. Protect one API with the adapter.
  2. Add signed trust and policy bundles.
  3. Expand to more routes, sources, agents, teams, and environments.
  4. Feel the operational pain of manual signing, source lifecycle, revocation, audit evidence, ownership, approvals, RBAC, compliance posture, and fleet status.
  5. Connect Auth fleets to Control when governance and managed lifecycle become valuable.

This path preserves Auth’s usefulness at every stage. A team can continue to operate Auth manually with local signed bundles. Control improves governance and operations; it is not required for local or manual operation.

Component Role Boundary
TrustPlane Auth Enforcement plane — deployable customer-side runtime, free to use Protects requests locally with adapters, verifiers, brokers, signed bundles, route/source policy, replay checks, and audit-ready allow/deny outcomes. It can run without Control.
TrustPlane Control Governance plane — enterprise offering, delivered as managed SaaS, governing many Auth deployments Manages bundle distribution, revocation, audit ingestion, approvals, RBAC, policy history, fleet inventory, heartbeat, and status across Auth fleets. It is not called synchronously for each protected request. TrustPlane Edge is the self-hosted deployment of Control with advanced, tailored capabilities.

The relationship is not “one Auth instance gets one Control Plane.” A Control tenant can govern many Auth fleets and deployments.

Protected request handling remains local:

request -> local Auth -> upstream

An acceptable Control integration is asynchronous or out-of-band for the request path:

Control -> signed bundles / revocations / policy history -> Auth deployments
Auth deployments -> audit events / heartbeat / status -> Control

This keeps the runtime portable across clusters, VMs, edge nodes, restricted networks, and customer-managed environments.

  • Auth remains independently useful without Control.
  • Control never becomes required for local or manual operation.
  • The trustplane CLI has no enroll, onboard, control, or Control administration commands.
  • Verification decisions are always made locally by Auth, even when the bundles it verifies were signed and distributed by Control.