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 workspace intent and receives operational evidence. 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. Validate it against the schema for the release you deploy.
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 current Linux/systemd path is elevated and registers the launcher unit to run as root by default; do not infer a rootless, Windows, or macOS equivalent without current release documentation.
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. Obtain the current customized file.
Open Trust & Receipts in the authenticated workspace and download
infraveil.py. Use the browser-hash-verified customized file and the verification information delivered for that release. - 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, while 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, the intended agent release is current, services are running, health checks are passing, and configured routes are reachable. These are separate states and may diverge.
Review the customer host and hosted evidence together: release hash, process state, health results, restart pressure, cache state, gateway decisions, and command receipts. A hosted success label should be checked against customer-side runtime evidence for critical changes.
Customers remain responsible for operating-system maintenance, network policy, application dependencies, secrets, data, backups, capacity, and workload-specific incident response.
Recovery and offboarding
Recovery is configuration- and workload-dependent. Test control-plane interruption, restart-budget exhaustion, an unhealthy candidate, cache fallback, disk pressure, and rollback compatibility before relying on those paths.
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.