An optional Pilot-hosted federation, policy, approval, monitoring, and command plane for one agent or a managed fleet.
+ +The hosted control plane lets an organization describe what its agents may do, evaluate proposed actions before execution, request human or service approval, inspect actions and exchanged content, operate nodes remotely, and retain signed evidence. It is adjacent to the open Pilot node and protocol: installing Pilot does not automatically place an agent under hosted control.
+Four boundaries are fundamental:
+| Mode | Behavior | Hosted dependency |
|---|---|---|
off / no hook | The original agent and node behavior is unchanged. | None |
observe | Selected actions are recorded without blocking them. | Optional |
local_enforce | Signed deterministic rules may deny or constrain locally. | No per-action hosted decision |
managed_enforce | Selected actions wait for the hosted deterministic, semantic, and approval path. | Required for governed actions |
Action interception and .pilot state synchronization are separate toggles. Signed fleet reporting is required for a managed adoption because it is how the service verifies the allocated node and returns typed control operations. A newly released action is not silently governed: enforcement profiles use an explicit action inventory or a visible wildcard.
| Component | Location | Responsibility |
|---|---|---|
| Pilot node runtime | Agent host | Node identity, trust pins, signed policy, enforcement, receipts, fleet reporting, and state reconciliation. |
| Harness adapter | Agent host | Optional native pre/post hooks or MCP bridge around the action boundary exposed by the harness. |
| Management service | Pilot-hosted | Accounts, organizations, policies, approvals, fleet desired state, procedures, audit, evidence, monitoring, and integrations. |
| Federation service | Pilot-hosted, tenant routed | Receives signed action intents and exact eligible exchange content; returns a signed narrowed decision. |
| Semantic evaluator | Pilot-hosted | Evaluates only active reviewed clauses, records model/version/usage evidence, and never grants above deterministic policy. |
In managed enforcement, Pilot may receive the complete tool arguments, message body, explicit file-share bytes, HTTP body, transaction details, and reported result when the selected adapter exposes them. The exchange record binds exact content to the called resource, hashes, policy revision, decision, and retention metadata. Authorized operators can inspect a bounded preview and audit access to complete retained content.
+No hidden local semantic inspector is installed. If content must be interpreted semantically, the eligible exchange is routed through the Pilot-hosted federation boundary. With no active semantic clause, deterministic evaluation completes without a model call. Actions configured as local-only remain metadata-governed unless an adapter deliberately federates inspectable content.
+Private keys, enrollment seeds, account passwords, and root signing material are not rendered in the management interface. The .pilot state view fingerprints protected artifacts and permits mutation only for the explicitly safe, revision-checked subset.
How people, service accounts, organizations, tenants, sessions, and adopted agents are separated.
+ +/v1/auth/signup returns 404 {"error":"signup_unavailable"}. The live login page is available, but accounts must already exist or be created through an invitation or operator-assisted provisioning path.The deployed management service serves a preconfigured demonstration organization and supports an ordinary login flow. It is not an open registration service. A person needs a valid existing account or an unexpired, single-use invitation issued by an organization administrator. This is intentional: the development-only open signup route is forbidden in production configuration.
+After account creation, the first-party identity path supports local password login, password reset, logout, session inventory and revocation, TOTP multifactor authentication, recovery codes, member suspension, and optional OIDC federation. OIDC is an integration, not a prerequisite.
+ +The public SaaS code implements the following workflow, but that provisioner is not deployed on the live service:
+No password should pass through the global signup service. It verifies and provisions the workspace, then hands the browser to the isolated account origin.
+ +Each authority binds one organization to one cryptographic tenant. Browser sessions obtain tenant scope from the authenticated account context; a tenant_id query parameter cannot switch the user into another organization. Object stores and repository keys repeat tenant ownership checks, while signed node artifacts carry the same tenant identity.
Enrollment tokens, node credentials, trust bundles, policies, decisions, receipts, fleet reports, exchanges, audit records, and usage units are tenant-bound. A token issued by Organization A cannot produce an Organization B identity. Separate authority cells are the recommended hard boundary for unrelated customers; pooled placement additionally requires database- and credential-level isolation before general release.
+ +The product model supports many organizations, each with its own slug, tenant, authority, members, policies, nodes, and evidence. The current live deployment does not yet expose that public multi-organization provisioning layer.
+Permissions separate account administration, policy writing, independent policy approval, consent voting, trust and mandate administration, fleet commands, integration management, evidence access, and audit administration. Browser mutations require a session-bound CSRF token and same-origin validation.
+| Identity | Use | Lifecycle |
|---|---|---|
| Organization owner/admin | Members, roles, security configuration, and delegated administration. | Protected against removing the final administrator. |
| Member | Role-scoped console and API access. | Invite, activate, suspend, reactivate, remove. |
| Service account | Non-browser automation with explicit permissions. | Create, rotate API keys, disable, revoke. |
| Node identity | Signs agent intents, reports, acknowledgements, results, and receipts. | Adopt, rotate, quarantine, retire, revoke, re-adopt. |
Plans are disabled for the initial public launch. Every organization receives the same launch entitlement; users do not select a tier, enter payment details, see upgrade prompts, or pass through Stripe. Billing and plan-management routes must remain hidden or return a clear disabled state.
+Planless does not mean unbounded. Every tenant still needs hard node, request, semantic-token, storage, retention, and event limits plus rate limiting and abuse controls. Semantic/model usage is attributed by tenant, agent, evaluator, model call, and token counts through an idempotent usage ledger for cost visibility and future product decisions, but it is not invoiced.
+The data model may retain internal entitlement fields so plans can be introduced later without a tenant migration. Those fields are operational defaults, not a customer-visible commercial contract while plan mode is disabled. A metering or quota failure must never expand action authority.
+ +Invitations, sessions, API keys, members, and nodes have explicit terminal states rather than destructive deletion where evidence must remain verifiable. Organization rename, export, deletion, suspension, owner transfer, legal holds, final-admin protection, node revocation, subdomain cleanup, and usage-ledger closure must behave atomically before public SaaS launch. Those complete organization-lifecycle tests remain a release gate.
+ +Adopt the core Pilot node first; attach a harness action boundary only when in-flight control is wanted.
+ +fleet.command role.pilotctl and pilot-daemon..pilot state synchronization. Fleet reporting is required.curl -fsSL https://pilotprotocol.network/install.sh | \
+ PILOT_ENROLLMENT_TOKEN='<one-time token>' sh -s -- \
+ --managed-url https://management.pilotprotocol.networknpx -y pilotprotocol-mcp@0.2.13 attach --gemini.The token is a short-lived bearer secret. Do not put the generated command in tickets, chat, source control, shared shell history, process supervisors, or screenshots.
+ +The installer downloads the management-authority-pinned managed runtime, then calls pilotctl enterprise adopt. The service returns exactly one delegated node identity plus the public root pin, signed trust bundle, signed bootstrap policy, organization endpoints, adoption options, and run identity. The browser never creates a node key.
The client verifies that the credential, key, trust bundle, policy, tenant, agent ID, and HTTPS authority origins agree. It then atomically writes an owner-only attachment under $HOME/.pilot/managed/:
enterprise-control.json — tenant, endpoints, policy paths, action inventory, rollout, reporting, and state-sync configuration;trust.json and policy.json — verified signed bootstrap artifacts;agent.seed — the delegated node seed, stored with owner-only permissions;The enrollment token is stored server-side only as a hash, consumed before private credential material is released, removed from the process environment, and never reused. Unknown, expired, and consumed tokens return the same generic error.
+ +| Option | When enabled | When disabled |
|---|---|---|
| Fleet connection | Signed health, desired state, rollout, and typed commands. | Not a managed adoption; this option is required. |
| In-flight action control | Selected harness actions wait for signed hosted decisions and produce receipts. | Ordinary harness actions remain unchanged. |
.pilot state visibility | Safe state manifests and revision-checked mutations synchronize over the fleet channel. | No state tree or remote state mutation. |
Core adoption installs the node runtime; it does not install pilot-mcp. Harness attachment is a separate opt-in integration that reads the existing managed attachment. See Harness coverage.
The console does not trust a client-side success message. It checks:
+A managed identity is not portable between organizations. The installer deliberately refuses a new enrollment token when $HOME/.pilot/managed/enterprise-control.json already exists. To replace or move a node, an administrator must retire or revoke the old identity, preserve required evidence, remove the old managed attachment through an approved local decommissioning procedure, and issue a fresh organization-bound adoption. There is no public self-service cross-organization transfer workflow today.
Do not copy agent.seed or the complete managed directory to clone a node. Each runtime instance should receive a distinct delegated identity and appear separately in fleet inventory.
Running the ordinary Pilot installer without --managed-url and without an enrollment token preserves unmanaged behavior. Installing a harness adapter without a valid owner-only managed attachment is a zero-side-effect pass-through. Disabling or removing an optional harness boundary should restore the harness's original execution path, subject to that harness's own configuration.
A connector is only as complete as the native action boundary its harness actually exposes.
+ +| Harness | Current boundary | Important limitation |
|---|---|---|
| Claude Code | Live-verified PreToolUse, PostToolUse, and failure events for built-in and MCP tools. | A Bash hook sees the proposed command, not every syscall made by its child process. |
| Codex CLI | Native pre/post tool hooks plus Pilot MCP. | User hooks require review/trust; specialized hosted paths may opt out unless managed requirements cover them. |
| Gemini CLI | Native BeforeTool/AfterTool; real allow, result, and denial paths exercised. | Model-request interception is separate, and identical parallel calls have limited post-call correlation. |
| GitHub Copilot CLI | Local and repository preToolUse/postToolUse contracts. | Documented timeouts fail open; cloud agents need committed repository hooks and reachable ingress. |
| OpenHands | Claude-compatible pre/post hooks per repository. | User-home configuration is not fleet-wide; distribute the repository contract to every workspace. |
| OpenClaw | Bundled plugin for built-in tools, results, and outbound messages. | Only OpenClaw-owned paths are covered; retain sandbox and egress controls. |
| Hermes Agent | Native CLI/Gateway pre/post tool hooks; pinned wire protocol verified. | Malformed output, process death, and timeout behavior requires additional containment because upstream failure modes may be fail open. |
| Cline | Global PreToolUse/PostToolUse scripts for desktop and SDK-hosted tools. | Hook crashes and timeouts are documented as fail open; existing global hooks must be composed explicitly. |
| Cursor | Native pre/post tool hooks with fail-closed Pilot preflights. | User hooks do not reach cloud agents; use repository, team, or enterprise distribution there. |
| Continue | Pilot MCP calls plus Continue's static allow/ask/exclude permissions. | No universal external pre/post hook was found; do not claim whole-agent semantic control. |
| JetBrains Junie | Pilot MCP plus Junie's action allowlist. | Native Junie actions remain outside Pilot evaluation without a supported interception API. |
| PicoClaw | JSON-RPC process hooks for before_tool/after_tool. | The upstream runtime is pre-1.0. Pin and certify an exact build; it is not production-certified. |
| Any MCP client | Complete arguments and results for calls to the Pilot MCP server. | Installing Pilot MCP does not intercept other MCP servers or built-in shell, browser, or file tools. |
| Custom SDK host | Potentially complete BeforeAction/AfterAction wrapping around host-owned side effects. | Unwrapped adapters remain outside control; the host must attest and test the complete action inventory. |
Use the version-pinned command shown by the onboarding page. Examples:
+npx -y pilotprotocol-mcp@0.2.13 attach --claude
+npx -y pilotprotocol-mcp@0.2.13 attach --codex
+npx -y pilotprotocol-mcp@0.2.13 attach --gemini
+npx -y pilotprotocol-mcp@0.2.13 attach --openclaw
+npx -y pilotprotocol-mcp@0.2.13 attach --hermesThe adapter verifies that $HOME/.pilot/managed/enterprise-control.json is a regular owner-owned file with owner-only permissions. It merges supported hook configuration without deliberately replacing an unrelated existing hook. Some harnesses require an explicit restart, trust review, repository-level file, or first-use command approval; follow the connector-specific instructions displayed in the console.
Where the harness supplies it, a pre-hook sends the canonical action, called tool, complete parameters, explicit file bytes, destination, session and working-directory correlation, permission mode, and timing metadata. A post-hook adds the result, response content, duration, or failure. The hosted exchange makes those fields visible alongside the signed policy and decision.
+Coverage must be stated per event. An outbound-message hook can govern message delivery even when it is not a general tool hook. MCP coverage means Pilot sees calls to Pilot MCP, not the entire agent. A shell hook is not kernel mediation.
+ +Pilot can emit a valid deny when the hosted decision service is reachable but rejects or times out according to policy. It cannot prevent a harness from killing or bypassing its hook process if the harness itself defines that path as fail open. For high-risk actions, choose harnesses and deployment controls that can enforce the required failure posture.
+Pilot separates operator intent, executable policy, semantic interpretation, consent, rollout, and post-action response.
+ +| Surface | Use it for | Runtime effect |
|---|---|---|
| Signed policy rule | Exact node, action, resource, risk, disclosure, amount, destination, or approval behavior. | The first matching rule establishes the deterministic ceiling. |
| Policy statement | Human-readable restrictions such as “Do not accept trust from anyone.” | Compiles into reviewed deterministic rules and/or semantic clauses; no effect until rollout activation. |
| Semantic clause | Meaning that cannot be resolved from exact metadata, such as confidential content leaving the company. | A hosted evaluator may deny or request the pinned approval plan; it never grants above the base answer. |
| Approval plan | Eligible approvers, quorum, validity, approved outcome, and constraints. | May create one payload-bound, single-use continuation after quorum. |
| Procedure | Alert, investigate, quarantine, refresh, export, or notify after an outcome. | Runs after durable activity and cannot modify the original authorization. |
The managed action vocabulary covers browser navigation; process execution; arbitrary tool invocation; HTTP and webhook requests; data read, export, and text/JSON/binary send; file read, write, delete, and share; event publication; trust request, accept, auto-accept, reject, revoke; wallet payment; and custom registered actions.
+Policies also bind the target resource, risk, recipient, purpose, labels, content type, residency, retention class, transaction value, destination, and node scope where relevant. An adapter must report an action before Pilot can govern it. Publishing a rule does not create interception.
+ +* means all nodes in the tenant.A prose sentence is never sent directly to a model as unrestricted authority. It remains a revisioned source object bound to the reviewed compilation and active signed policy revision.
+ +Editing produces a higher immutable revision. Removing a rule is also a reviewed signed change. Rollback creates a new higher revision rather than lowering a node's rollback floor.
+ +No active semantic clause means no model call and no semantic usage charge. High- and critical-risk failure posture should be explicitly fail closed when the business requirement cannot tolerate an unevaluated action.
+ +An approval plan is tenant-scoped and immutable by revision. It lists purpose-limited approver keys, required quorum, validity duration, approved outcome, and optional constraints. A transaction binds the exact signed intent and payload hash. Distinct eligible signatures count toward quorum.
+Approval is not a reusable exception. Quorum creates one single-use continuation for the same request. Rejection, cancellation, expiry, payload mismatch, agent mismatch, plan mismatch, or replay remains blocked. The node stores payload-free continuation state with exclusive creation and a restart-safe lease so at most one resume attempt can occur.
+ +| Operator statement | Compiled or runtime meaning |
|---|---|
| Don't accept trust from anyone. | Deterministic deny for trust.accept and trust.auto_accept on the selected nodes. |
| Do not transact with Acme. | After binding Acme to a canonical merchant resource, deny matching wallet.pay actions. |
| Do not send confidential material outside the company. | Explicit send/share scope plus a reviewed hosted semantic clause that may deny or request security approval. |
| Finance may pay approved-vendor up to 1,000 USD. | Structured node/action/resource rule with amount and destination constraints. |
Signed inventory, desired state, typed control, exact exchange evidence, audit, monitoring, and bounded automation.
+ +The native management dashboard summarizes connected nodes, policy coverage, decision outcomes, pending approvals, evaluator health, command state, and recent activity. Fleet views support server-side filters and pagination for node status, group, tag, policy drift, connector capability, runtime version, and last report time.
+Each node detail joins its signed identity, harness and connector versions, uptime, counters, connectivity, current and desired policy revisions, groups, tags, quarantine posture, recent actions, receipts, commands, state root, and acknowledgements. A stale or missing report is visible; the UI does not silently treat configured state as observed state.
+ +Authority-signed desired state can set group, tags, desired runtime version, desired policy revision, and quarantine posture. The node verifies the command key and monotonic floors, persists before applying, reconciles locally, then returns a signed applied, partially_applied, or rejected acknowledgement. Drift remains visible until the reported state converges.
Runtime version is a desired target, not permission for the control plane to replace arbitrary executables. The deployment supervisor remains responsible for changing installed software.
+ +Remote operations are typed, targeted, authority-signed, reason-bound, expiring, cancellable, and auditable. Supported commands are:
+refresh_policy — fetch and acknowledge the current signed rollout;export_receipts — flush pending signed receipt evidence;reload_control — reload the verified local control attachment;sync_state — report and reconcile the safe state tree;collect_diagnostics — return bounded diagnostic status;restart_runtime and shutdown_runtime — graceful typed lifecycle requests.Pilot is not a remote shell. Operators cannot type arbitrary commands into the fleet console. Nodes return bounded signed result codes, and protected local authority cannot be widened through command parameters.
+ +.pilot state visibilityAn adopted node can report a signed manifest of its managed state directory: relative paths, file or directory kind, size, mode, modification time, content hash, revision, and root hash. Safe text files may expose sanitized or bounded content. Keys, seeds, credentials, identity, policy internals, trust material, and rollback floors are fingerprint-only and immutable through this channel.
+Supported state changes use optimistic concurrency. A mutation names the expected tree revision and existing file hash, contains an auditable reason, expires, and is signed by the authority. The node independently validates safe paths and modes, applies the change locally, and reports the resulting signed revision. History records additions, changes, removals, and root hashes.
+ +The Exchanges workspace stores tenant-scoped request and response evidence with server-side search and pagination. A detail view correlates:
+Browser previews are bounded. Complete retained objects require explicit evidence permission and an audited download. Audit metadata and exact exchange content are separate stores with different access and retention concerns.
+ +Management mutations write an append-only attempt event and a terminal result event. Records include actor, roles, authentication method, operation, reason, correlation ID, status, duration, and request/response hashes without copying secrets. Operators can filter, paginate, inspect, export NDJSON, monitor continuous delivery, and retry dead-letter exports.
+Investigations have assignee, severity, status, resolution, timestamps, and links to action, exchange, receipt, command, and audit evidence. Legal hold and retention policy preserve required objects. Signed action receipts are verified at ingest and may be mirrored into compliance-retention object storage.
+ +Procedures are immutable, revisioned, post-action response policies. Triggers match action, node, risk, decision, or observed result. The closed response vocabulary can create an alert, open an investigation, quarantine a node, request policy refresh, request receipt export, or notify an active integration.
+A run is durable and idempotent for the activity and procedure revision. Procedures cannot grant or retry the original action, inspect arbitrary content, execute shell commands, or invent remote methods.
+ +| Kind | Purpose | Lifecycle |
|---|---|---|
| OIDC / Keycloak | Optional workforce identity federation. | Stage, inspect, probe, activate, rotate, disable. |
| OpenBao / KMS | External signing-key custody. | Reference-only secrets and signature verification. |
| S3-compatible Object Lock | Immutable receipt and evidence mirror. | Retention and legal-hold evidence. |
| PostgreSQL | Replica-safe shared authority state. | TLS, migrations, backup, restore, and health. |
| Prometheus-compatible storage | Metrics retention. | Pilot's native UI remains the operator dashboard. |
| Usage sink | Asynchronous idempotent commercial usage delivery. | Tenant-scoped credentials and delivery health. |
| Audit/SIEM and webhook | Management export, approval, and procedure notifications. | Retry, dead letter, health, and rotation. |
Connectors store secret references, not rendered secret values. Hosted semantic evaluation is Pilot platform infrastructure and is not configured as a customer-owned integration.
+ +| Object | Create | Change | Terminal behavior |
|---|---|---|---|
| Node | One-time adopted identity and signed report. | Desired state, tags, groups, quarantine, commands. | Retire or revoke; reactivate only where policy permits. |
| Policy statement | Inactive source revision. | Compile, review, approve, deploy. | Reject or retire; signed policy removal is a higher revision. |
| Policy change | Draft candidate. | Diff, simulate, approve, publish, canary, promote. | Withdraw, terminate, or monotonic rollback. |
| Approval transaction | Exact intent and payload binding. | Vote, escalate, cancel. | Execute once, reject, cancel, or expire. |
| Procedure | Inactive draft revision. | New revision, activate, disable. | Retire while retaining run evidence. |
| Integration | Staged revision. | Probe, activate, rotate, disable. | Retain revision and audit history. |
What is live, what has been proved, and what still prevents a general production launch.
+ +| Capability | Status | Meaning |
|---|---|---|
| Management login | Live | The HTTPS login page is reachable and existing accounts can authenticate. |
| Public account signup | Not deployed | /v1/auth/signup returns signup_unavailable; new unrelated organizations cannot self-register. |
| Organization availability | Single preconfigured tenant | The live service currently serves the Pilot demonstration organization. |
| Managed node adoption | Live for the configured tenant | Short-lived one-time enrollment, verified delegated identity, bootstrap policy, and signed first report work. |
| Policy and semantic denial | Validated | A real Gemini-driven adopted agent was denied before executing a prohibited command; the expected filesystem side effect was absent. |
| Policy, approval, fleet, state, audit UI | Validated pre-release | Primary CRUD/lifecycle paths and 31 management pages have passed production-host UI sweeps. |
| Harness adapters | Mixed by harness | Several native paths are verified; partial and fail-open connectors remain explicitly labelled. |
| Plans and payments | Disabled by product decision | Public launch has one common entitlement, no checkout, no upgrade UI, and no customer charging. Usage remains measured for cost control. |
| Public multi-tenant platform | Not deployed | The SaaS provisioner, pooled runtime, account subdomains, and workspace controller are implemented/tested locally but not installed in the hosted GCP environment. |
process.execute action; Pilot denied it and the intended file was not created..pilot state create/read/history/delete, monitoring, traffic, approvals, audit, investigations, integrations, and readiness pages.These proofs establish that the core security concept works. They do not establish the operational, organizational, and provider controls required for a generally available SaaS.
+ +There are seven launch gates. Plans and Stripe are deliberately disabled and are not an eighth gate.
+A service being deployed on a production hostname is not enough. General production readiness requires all of the following:
+| Use case | Recommendation |
|---|---|
| Internal demonstration with the existing tenant | Yes. The live environment and permanent proof agents support this use. |
| Supervised design-partner evaluation | Yes, with a written scope, connector boundary, data/retention agreement, and operational owner. |
| Single-organization production pilot | Conditional. Perform organization-specific threat modelling, capacity tests, backup/restore, key custody, and incident readiness first. |
| Open public self-service SaaS | No. Signup, provisioning, multi-tenant hardening, planless cost controls, and cloud platform gates remain. |
| Regulated or safety-critical autonomous production | No general approval. It requires independent assurance, exact harness certification, retention/legal review, and customer-specific controls. |
A managed account provides a dedicated, managed Teleport cluster. This document describes account setup, billing, and connecting infrastructure.
+ +A new cluster is provisioned when signing up for a managed service. The first user is granted administrator privileges. Other team members can be invited, and roles and permissions can be configured.
+ +The subscription is managed through a customer dashboard. Several tiers are offered.
+The Teleport agent is required to connect servers, databases, or Kubernetes clusters. The agent establishes a reverse tunnel to the managed Teleport cluster.
+teleport start --roles=node --token=YOUR_JOIN_TOKEN --auth-server=your-cluster.teleport.sh:443The Netlify Managed Control Plane is a dedicated, single-tenant instance of Netlify’s control plane for enterprise teams. It provides the developer experience of the multi-tenant platform with additional security, compliance, and performance features.
+ +The Managed Control Plane is deployed in a dedicated environment within a chosen cloud region. Netlify manages the infrastructure, updates, and maintenance.
+Developers interact with the Managed Control Plane through the Netlify UI, CLI, and API. The underlying infrastructure is dedicated to a single organization.
+ +The Managed Control Plane requires an Enterprise plan. Netlify provisions a dedicated instance and provides a unique URL to access it, for example:
+https://app.your-company.netlify.comAfter setup, team members can be invited, Git repositories connected, and sites deployed from the control plane.
+ +Tailscale coordinates key rotation, node registration, and user authentication for devices. When a device is added to a tailnet, Tailscale generates a unique identity for it and handles key rotation.
+ +The machines page of the admin console provides a central inventory of all devices in a tailnet. For each device, it shows:
+This page can also be used to perform actions on devices, such as disabling key expiry or deleting a device from a tailnet.
+ +Tags can be used to apply policies to groups of devices. For example, a tag called `prod` could be created for production servers. A policy could then be created that only allows users with the `prod` tag to access those servers.
+ +Auth keys can be used to pre-authorize devices to join a tailnet. This is useful for automating the process of adding new devices, such as when provisioning new servers.
+ +Managed Harnesses define a set of environment variables and volumes that are automatically applied to a local development environment when connecting to a cluster. This feature is part of the Telepresence Pro plan.
+ +When connecting to a cluster with a Managed Harness, Telepresence automatically mounts specified volumes to the local machine and sets specified environment variables in the local shell. This provides a consistent development environment across a team without requiring manual configuration on each developer's machine.
+ +To create a Managed Harness, create a `harness.yaml` file in the project root. This file defines the environment variables and volumes to be applied.
+env:
+ - name: DATABASE_URL
+ value: postgresql://user:password@localhost:5432/mydb
+ - name: REDIS_URL
+ value: redis://localhost:6379
+volumes:
+ - name: my-volume
+ mountPath: /app/dataApply the file to the cluster:
+telepresence harness apply harness.yamlA Managed Harness is automatically used by any Telepresence client connecting to a cluster where the harness has been applied. No client-side configuration is needed.
+The connection output shows the harness being applied:
+telepresence connect
+...
+Applying managed harness...
+ - Setting environment variable DATABASE_URL
+ - Setting environment variable REDIS_URL
+ - Mounting volume my-volume
+...
+Connected to clusterVerify the environment variables and volumes in the local shell.
+ +Before connecting the first host to Teleport, the cluster must be ready to accept connections. This guide explains how to ensure the cluster is properly configured.
+ +The following are required before beginning:
+Check the health of the Teleport cluster by running the tctl status command on the Teleport Auth Service node.
+tctl status
+Cluster teleport.example.com
+Version v15.1.2
+CA pin sha256:abcdef1234567890abcdef1234567890abcdef1234567890abcdef123456The output shows the cluster name, Teleport version, and CA pin. Any errors must be resolved before proceeding.
+ +Agents require a publicly accessible cluster address to connect. This is configured in the teleport.yaml file on Teleport Proxy Service nodes.
+proxy_service:
+ enabled: "yes"
+ public_addr: "teleport.example.com:443"The public_addr must be set to the address nodes use to connect to the Teleport Proxy Service. This is often a load balancer or a DNS record pointing to the proxy nodes.
+ +After the cluster is ready, infrastructure can be connected. Guides are available for adding:
+