The operating boundaries.
One summary of responsibilities and evidence.
Infraveil is a hosted backend operations management plane paired with customer-side launcher and agent components. It is designed to coordinate desired state, approved runtime execution, managed gateway policy, operational evidence, incidents, status, catalog, and bounded recovery for configured services.
Backend operations are often divided among deployment, observability, incident response, cloud management, security, status, analytics, and local automation. The operational problem appears where their state, permissions, identifiers, and recovery procedures meet.
Specialized products can solve valuable parts of that problem. The customer still needs to determine which state is authoritative, which system may act, how actions are approved, and how to reconstruct an event after partial failure.
Infraveil's operating hypothesis is that desired state, host coordination, package verification, process supervision, managed gateway policy, evidence, incidents, status, catalog, documentation, and bounded recovery benefit from one coordinated model.
The hosted management plane records desired and observed state and presents operator workflows. The customer-side launcher and agent perform approved work on configured infrastructure. The customer retains ownership of infrastructure, code, credentials, data obligations, and approval policy.
Product comparisons should cover launcher authority, agent supervision, package verification, cached continuity, health checks, restart budgets, evidence, incident state, status, catalog, recovery behavior, and customer-side inspectability.
The launcher coordinates enrollment, desired-state synchronization, action acknowledgement, runtime reporting, and agent lifecycle. The agent verifies approved packages, supervises configured services, enforces restart limits, and reports operational evidence.
Architecture explains the intended mechanism; tests and runtime evidence show observed behavior for a particular version and environment. A failed or incomplete run must remain part of the record.
Customer-side source visibility supports inspection of the installed launcher and agent. It does not establish parity with a public snapshot, publish the proprietary hosted plane, or prove reliability without current test evidence.
Centralized authority creates concentration risk. Customers should assess tenant isolation, permissions, key handling, auditability, hosted-plane dependence, local continuity, removal paths, and recovery limits.
Disconnected products create coordination risk. The appropriate comparison measures handoffs, stale-state exposure, recovery effort, and operator error under the customer's actual workflow.
An integration can exchange data or invoke an action. It does not by itself establish one desired-state model, execution authority, action receipt, or recovery contract.
A suite may coordinate these responsibilities or may retain separate state and support boundaries. Customers should inspect implemented behavior rather than infer cohesion from packaging.
Similar category or feature language does not establish equivalent systems. Compare the source of truth, local execution path, approval mechanism, degraded behavior, evidence, and contract.
Exit planning should cover data export, customer-side packages, route changes, credential rotation, access removal, and any pre-existing hosted files. Fresh external attach may create a manifest-only active package while leaving pre-existing files in place.
Infraveil is designed to reduce coordination work within its configured scope. It does not claim to replace upstream volumetric protection for customer workloads, every specialist tool, or customer responsibility for application and infrastructure operation. OVHcloud and Cloudflare layers protecting configured Infraveil-hosted public paths complement rather than expand that scope.
Current, planned, internal-standard, contract-only, and unknown capabilities must remain separate. Fine-grained RBAC, SSO/SCIM, SOC 2, full air gap, self-hosting, residency, and SLA are not universal current claims.
This whitepaper describes the operating problem, architecture, responsibility boundaries, evaluation method, privacy controls, failure behavior, pricing facts, and recovery limits. Signed agreements take precedence where applicable.
New runtime hashes require the customer key. Manual, allowlist, and auto modes determine how signing occurs; they do not mean every action waits for a person.
Delivery and caches use encryption in defined places. The platform does not claim universal encryption at rest across every hosted and customer-controlled location.
The decision standard is bounded: inspect the current components, use the supported installation path, exercise approvals and failure paths, review receipts and exports, and decide whether the observed model fits the intended environment.
The decision rests on scope, evidence, and responsibility.
Infraveil coordinates a defined backend operating loop through a proprietary hosted plane and customer-side runtime components. The backend remains visible, and material customer responsibilities remain in place.
The launcher and agent provide the inspectable runtime path. The hosted plane coordinates access, state, evidence, incidents, catalog, status, and recovery workflows. Availability and exact scope depend on current implementation, configuration, and agreement.
Judge the platform by the supported path, current controls, version-specific evidence, documented limitations, published pricing, privacy choices, and signed commitments. Treat architecture as an explanation and test records as observations.