Hosted coordination, customer-side execution
Hosted by Infraveil
Accounts, workspaces, the management interface, desired-state coordination, artifact and command metadata, and received operational evidence are provided as a hosted service.
On customer-controlled hosts
The Trust Console, launcher, agent, service processes, managed workspace, cache, gateway, local receipts, and configured persistent paths can operate on customer infrastructure.
The hosted management plane is proprietary. Public-source parity with the current deployable launcher and agent has not been established; customers should inspect the components actually delivered to their hosts.
The customer key controls exact release-hash approval
The Trust Console keeps the customer Ed25519 private key on the customer machine. The hosted service receives the public key and signatures over exact release hashes.
Manual mode prompts before signing each pending hash. Allowlist mode signs only exact hashes the customer placed on the allowlist. Auto mode signs every control-plane-requested hash and therefore does not preserve a practical per-release customer veto while enabled.
This release gate is distinct from dashboard permissions, AI proposal handling, service health, and successful execution. Each needs its own evidence.
Source custody is selected per workload path
| Mode | Active package | Local disk behavior | Important limit |
|---|---|---|---|
| Source custody | May contain application files, the manifest, and package metadata. | Process mode can materialize application files in the managed workspace and always stores the manifest/package needed for the runtime path. | The customer must review code, secrets, generated files, and persistent paths before packaging. |
| No-source attach | A fresh attach creates a manifest-only active package with source_custody disabled. | The runtime still stores the manifest, package, local state, cache, logs, and receipts used for coordination and operation. | Pre-existing hosted application files may remain after changing modes and require explicit inspection or cleanup. |
A custody label describes the selected package path. It is not a claim that no application-related bytes can exist anywhere on disk, in process memory, in logs, in caches, or in customer-managed persistent paths.
Persistence is path-specific
Holds the manifest, package material, and application files when the selected custody and process mode require them.
Can retain approved package history or last-known runtime material used by bounded fallback and recovery paths.
Hold workload data the customer deliberately excludes from routine replacement. Backup and migration remain customer responsibilities.
Local and hosted subsets may include health, process, gateway, security, command, and recovery records under the configured product path.
TLS, signed metadata, encrypted credential fields, and protected caches are used in defined parts of the system. This page does not claim universal encryption at rest for every hosted record, customer filesystem, log, cache, artifact, or persistent data path. Confirm storage controls and retention for the current service and applicable agreement.
Controls apply to configured gateway traffic
The customer-side gateway can apply configured routing, request inspection, rate limits, policy decisions, and traffic evidence to requests that traverse managed routes.
Traffic that reaches an application through another listener, load balancer path, direct origin address, private network route, or misconfigured proxy can bypass those controls. Customers must validate the actual exposure path and restrict unintended origin access.
These are origin-side application-layer controls. Infraveil-hosted public endpoints currently use OVHcloud upstream Anti-DDoS infrastructure for OVH-hosted public IPs and Cloudflare for configured proxied web traffic. Those provider layers complement the gateway; they do not turn it into upstream protection or extend automatically to customer workloads. Customer workloads still need appropriate provider, CDN, or scrubbing mitigation and should restrict direct origin access. Unproxied records, non-HTTP services, saturated links outside provider mitigation, and bypass listeners remain separate responsibilities.
Operational metadata supports coordination
| Data | Direction | Purpose | Customer action |
|---|---|---|---|
| Desired state and commands | Hosted plane to customer host | Reconciliation and bounded operations | Review targets, approval mode, and policy |
| Machine and runtime state | Customer host to hosted plane | Status, diagnosis, evidence, and coordination | Review collection and retention |
| Artifacts and signatures | Release paths in both directions | Integrity, authenticity, and customer approval | Protect the key and verify exact hashes |
| Application and security signals | Configured local collection to hosted views | Incidents, status, gateway decisions, and investigation | Avoid secrets and define suitable redaction |
Continuity is bounded, not guaranteed
Local workloads may continue from explicit current or cached state, while coordination, new approvals, reporting, and revocation delivery can be delayed.
Configured health gates and restart budgets can stop a transition or limit restarts. They do not repair application logic or incompatible data changes.
Recovery depends on customer backups, capacity, permissions, persistent-data design, and a known-good replacement path.
A hosted revocation record does not prove that a disconnected host has already received and applied the change.
Confirm deployment-specific requirements
Fine-grained RBAC, SSO or SCIM, SOC 2 status, full air-gap operation, a self-hosted management plane, data residency, contractual SLA, recovery targets, regional layout, and support access are not represented here as current universal capabilities. Confirm them against current product documentation and the signed agreement for the deployment.