The authenticated Trust & Receipts flow and its Trust Console own bootstrap, customer-key setup, enrollment, dependency validation, launcher installation, and install verification. A standalone launcher.py and Customization/config.json describe legacy paths and are not the current onboarding contract.
Overview
Infraveil combines a hosted management plane with customer-side runtime components. The hosted side coordinates releases, configuration, inventory, placement, and supported actions, and receives operating state. The Trust Console, launcher, agent, service supervisor, gateway, managed workspace, cache, and configured persistent paths operate on customer-controlled hosts.
The runtime contract is infraveil.json. It defines supported services, routes, health behavior, restart limits, ordering, environment requirements, and persistence. Check the fields consumed by the current runtime and its release-specific documentation; a manifest version label alone is not a compatibility guarantee.
Requirements
Supported customer host
Use an operating system and service-manager path listed for the current release. The customized one-file Trust Console, infraveil.py, currently requires Python 3.10 or later.
Appropriate local authority
Installation can make system-wide changes. The automatic Linux/systemd path requires the intended non-root setup user and registers the launcher with that user's numeric identity, a private umask, and no new privileges. System-wide registration still uses privileged operations. A privileged service requires separately reviewed provisioning with protected executable paths; other service-manager paths need their own release-specific validation.
Network path
The host needs the documented outbound HTTPS path to the hosted service. Inbound exposure and DNS are required only for routes the customer chooses to publish.
Application contract
The workload must have a valid infraveil.json and the runtimes, dependencies, secrets, data stores, and health behavior its services require.
Enrollment with the Trust Console
- 1. Use the target-server setup command.
Open the authenticated workspace’s connection flow and copy its current curl command. Run it on the target supported Linux server and follow the verification and Trust Console prompts for
infraveil.py. Use the workspace-generated command rather than a command copied from a public example. - 2. Run the short-lived bootstrap.
On first run,
infraveil.pyuses a five-minute, one-use bootstrap capability. The Trust Console creates or loads the customer-held Ed25519 approval key, enrolls the workspace, validates its locked dependencies, and obtains a host-bound, one-use launcher ticket for the supported install path. - 3. Choose approval behavior.
Manual prompts before signing each pending hash. Allowlist signs only exact hashes the customer has listed. Auto signs each control-plane-requested hash and removes the practical per-release veto while enabled.
- 4. Verify and protect the installation.
Treat enrollment as complete only after the supported flow reports a verified install. Keep the approval key, machine credentials, runtime files, cache, and logs under operating-system permissions and backup rules appropriate to their sensitivity.
The private approval key remains on the customer machine. Infraveil receives the public key and exact-hash signatures needed for the configured approval workflow.
Runtime contract and exposure
Commit infraveil.json with the application and review it like code. Use the current validator rather than an example copied from this whitepaper; field availability and compatibility can change by product version.
Choose the custody mode deliberately. A source-custody package may include application files as well as the manifest. A no-source attach uses a manifest-only active package for a fresh attach and observes existing systemd services without taking application deployment or restart ownership. The attach path does not run install, build, or start commands; the existing service manager remains responsible for the process. Files from an earlier hosted package may still require explicit cleanup.
Publish only configured routes after confirming local health, bind addresses, DNS, TLS, upstream targets, and bypass paths. Gateway enforcement applies to traffic that traverses the configured gateway. It is not upstream volumetric DDoS scrubbing. Provider layers used for Infraveil-hosted public endpoints do not establish equivalent coverage for customer workloads.
Operations
After enrollment, confirm that the launcher is synchronized, its assigned workloads are on the intended host, the agent release is current, service processes are running, health checks pass, and configured routes are reachable. App Logs contain captured application output; Runtime Logs describe the operating components. Request Trace covers observed managed traffic, while Control Trace describes runtime-control activity. These are distinct signals and may diverge.
Investigate one workload in its host context, then choose the supported action and explicit target scope. Fleet controls include placement, ordering and startup delays, drain from new assignments, capacity diagnostics, and selected-group commands. Confirm the reported outcome after dispatch. MCP clients use named workspace-scoped tools with authorization and preview/apply checks; they do not obtain a general shell or the release-signing key.
Customers remain responsible for operating-system maintenance, network policy, application dependencies, secrets, data, backups, capacity, and workload-specific incident response.
Recovery and offboarding
Managed process recovery uses configured retry budgets and delays; eligible package candidates can promote or restore known-good local state. Agent-runtime canary/batch rollout and rollback is a separate mechanism. Test interruption, exhausted retries, bad candidates, disk pressure, and compatibility. None of these is database restoration, zero-downtime application deployment, or automatic cross-host failover.
For a compromised host, restore or replace it from a known-good state, revoke the old machine identity, enroll the replacement through the Trust Console, validate the runtime contract, and reopen traffic only after local and external checks pass.
For offboarding, revoke enrolled identities, stop and remove customer-side services, remove local credentials and managed runtime state under the customer's retention policy, and separately handle application files, persistent data, DNS, TLS, and external integrations.
Use current product instructions for exact commands.
This whitepaper explains boundaries and responsibilities. It is not an install script, a versioned schema, or a substitute for the release-specific Trust Console prompts and authenticated workspace documentation.