01 · Fleet
Control plane
Desired state, placement, policy, rollout sequencing, identities, approvals, and command history across the fleet.
Transparency
The architecture behind
Infraveil.
What runs, where it runs, what the control plane can do, what remains on your infrastructure, and how every consequential action becomes evidence.
System map
One system. Four explicit layers.
Each layer has a distinct authority boundary. The dashboard does not become trusted merely because it drew a button.
02 · Machine
Launcher
The local machine supervisor. It verifies releases, owns agent lifecycle, reconciles desired state, and preserves recovery slots.
03 · Workload
Agent
A bounded operator attached to a workload. It supervises processes, enforces policy, reports health, and records evidence.
04 · Contract
infraveil.json
The runtime contract declaring services, routes, order, health behavior, restart rules, environment, and persistence.
Vocabulary
Learn the system once.
The same terms appear in the dashboard, runtime evidence, release process, and incident history. They are contracts, not branding.
Desired state
What the operator has asked the fleet to become: placement, policy, version, rollout order, and command intent.
Observed state
What launchers and agents prove is happening now: heartbeats, process health, metrics, hashes, queues, and receipts.
Receipt
A lifecycle record for an action: issuer, target, queued, acknowledged, completed or failed, and integrity evidence.
Local ledger
A hash-chained append-only record stored on the customer machine. The control plane receives the latest anchor, not authority to rewrite it.
Runtime evidence
Signed version, active source hash, service state, gateway state, cache state, and rollout outcome reported by the executing machine.
Possession before execution
Production authority starts outside the dashboard.
The customer creates and retains an offline Ed25519 approval key. Infraveil can prepare a release, but the launcher will not trust that release until the customer signature verifies locally against the enrolled public key.
01
Enroll possession
Generate the private key locally and enroll only its public identity.
02
Prepare release
Runtime bytes, version, source hash, and vendor signature become one candidate.
03
Approve locally
The offline private key signs the exact candidate hash.
04
Verify on machine
Launcher and agent verify vendor and customer approval before execution.
05
Prove outcome
Canary, batch, promotion, rollback, and active hashes become runtime evidence.
Failure semantics
Failure behavior is part of the product.
A control plane is credible only when it explains what happens after the happy path ends.
Control plane unreachable
Verified workloads keep running from local state. New fleet commands and cross-fleet convergence wait for the authenticated control path to return.
Network partition
Agents retain bounded event queues and expose queue pressure, retries, failures, and drops. Reconnection resumes synchronization without pretending the gap did not exist.
Agent process failure
The launcher applies restart budgets and suspends crash loops instead of restarting forever. The observed state records why execution stopped.
Bad runtime release
Candidate, active, and previous runtime slots preserve a local rollback path. Verification or customer approval can veto a candidate before it runs.
Launcher replacement
A replacement reconnects with machine identity, retrieves assigned desired state, verifies artifacts, and reconciles its agent set from the workspace model.
Compromised identity
Launchers and agents can be locked, revoked, quarantined, cache-purged, and issued rotated machine credentials through explicit emergency controls.
Boundary inventory
What crosses each boundary.
Machine → control plane
Heartbeats, capabilities, process and service health, bounded metrics, hashes, queue state, requested logs and traces, security events, receipts, and ledger anchors.
Control plane → machine
Assigned desired state, runtime contracts, policy, rollout metadata, scoped commands, signed runtime source, verified workload artifacts, and revocation state.
Remains local
Application execution, machine runtime cache, process environment, persistent workload paths, the full local audit ledger, and the customer's offline approval private key.
Fleet scope
Macro first. Evidence underneath.
Infraveil does not turn a thousand machines into a thousand unrelated pages. The fleet topology is the scope controller: begin with the entire workspace, narrow to a launcher, descend into its ordered workloads, then carry that focus into runtime, network, security, receipt, and recovery views.
Workspace fleet
All regions and launchers
Launcher cluster
Region, capacity, health, placement, rollout.
Signal cluster
Repeated events compressed by cause and pressure.
orders-api
policy-engine
event-gateway
task-runner
No focus
Workspace truth
Counts, health, pressure, placement, requests, and incidents summarize the complete fleet.
Launcher focus
Machine truth
Capacity, rollout order, agents, queues, logs, traces, receipts, and local evidence narrow to one host.
Workload focus
Process truth
The same surfaces resolve to one runtime without losing its fleet or machine context.
Aggregate without erasing
Repeated signals become clusters and pressure summaries, while their underlying events remain available for inspection.
One scope controller
Scope is selected from the topology instead of being reimplemented differently on every page.
Order remains visible
Launcher placement and workload rollout order remain explicit, editable state rather than hidden scheduler behavior.
Why a dedicated runtime
Runtime control without adopting a cluster religion.
Infraveil was built for software already running on customer-controlled servers. Requiring Kubernetes would move the adoption boundary, not remove it. The launcher and agent model supplies the specific reconciliation, supervision, evidence, security, and recovery primitives Infraveil needs without asking the customer to rebuild their infrastructure first.
Existing machines
Launchers attach to hosts the customer already operates. Applications remain on those machines and inside their existing network boundaries.
Application ownership
The control contract is infraveil.json, not an Infraveil-owned copy of the customer's repository. Application source remains under the customer's existing source and delivery controls.
Explicit contract
infraveil.json declares services, routes, health checks, order, persistence, restart behavior, and environment requirements.
Local reconciliation
The launcher converges machine state, supervises agents, applies rollout delay, enforces restart budgets, and continues from verified local state during control-plane loss.
Bounded workloads
Each agent owns one workload boundary: process tree, health, route gateway, policy, telemetry, cache, queue, and evidence.
No scheduler fiction
Placement, capacity, failover targets, rollout order, and recovery are first-class visible state instead of opaque automation.
Telemetry and enforcement
The data plane explains. The policy plane decides.
Metrics alone cannot explain a controlled runtime, and security events alone cannot operate one. Infraveil correlates machine health, process output, request behavior, policy decisions, and command evidence while preserving the boundary between observation and authority.
Observe
Runtime evidence
Heartbeats and capacity. CPU, memory, disk, uptime, capabilities, runtime identity, and queue pressure.
Logs and process state. Output, severity, restarts, health failures, crash-loop state, and process lifecycle.
Request traces. Route, method, response, latency, source context, security decision, and workload relationship.
Receipts and integrity. Commands, releases, hashes, approvals, audit anchors, rollout, and rollback outcomes.
Enforce
Request policy
Inherited or workload-specific. Fleet defaults can be inherited or deliberately overridden at a workload boundary.
Deterministic stages. Observe, fingerprint, detect, score, branch, limit, block, deceive, tarpit, log, or invoke a guarded analysis tool.
Edge-aware identity. Source and country data are accepted from configured trusted edges instead of arbitrary forwarding headers.
Visible consequences. Rate limits, firewall decisions, geo gates, honeypots, blocks, and threat signals become correlated evidence.
Bounded collection
Queues, previews, bodies, dictionaries, and local files have explicit caps. Backpressure, retries, failures, and drops are observable instead of silently hidden.
Trace redaction
Authorization, cookies, passwords, API keys, credentials, tokens, nonces, signatures, recovery codes, and matching nested fields are redacted before controlled traces are exposed.
Export and deletion
Operators can export workspace data, audit evidence, and proof packets, and can explicitly clear supported log and analytics stores. Exportability is not presented as live control-plane mirroring.
Controlled delivery
External integrations receive subscribed event classes through validated destinations and signed payloads. They do not inherit general workspace authority merely because they receive an event.
Release, placement, recovery
Change is staged. Failure has somewhere to go.
Fleet control is not complete when an artifact downloads. Infraveil carries a release through cryptographic approval, ordered placement, health observation, promotion, and local rollback, then records the path it actually took.
Candidate to active
Version, source hash, vendor signature, and customer approval define the candidate. Launchers and agents verify the same identity before execution.
Canary to controlled batches
A release begins with a canary and expands through ordered batches only after health evidence permits promotion.
Previous remains available
Candidate, active, and previous runtime slots retain a verified local fallback rather than depending on a fresh download during failure.
Placement
Spread or consolidate by region, labels, host capacity, weight, and per-host limits.
Rollout
Launcher and workload order, delay, batch state, and health gates remain operator-visible.
Failover
Offline hosts can move assigned workloads to selected or policy-chosen online capacity.
Rebalance
Recovery can converge placement back toward policy without erasing the failover history.
Workspace lifecycle
Authority can be narrowed, stopped, and revoked.
A workspace is the tenant boundary for paths, machine identities, desired state, telemetry, receipts, policy, and billing state. Launcher and agent identities are separate, signed machine principals inside that boundary.
StateControl-plane effectMachine effect
Operational
Authorized desired state, commands, telemetry, and releases remain available.
Verified workloads reconcile and report observed state.
Disconnected
New convergence waits; the gap remains visible.
Known-good workloads continue locally and queue bounded evidence.
Billing locked
Paid operations reject with explicit workspace-lock state.
Configured billing-continuity policy determines bounded local degradation or stop behavior.
Quarantined
The workspace is locked and emergency stop receipts are queued.
Launchers and agents receive stop state; cache purge can be requested.
Revoked
Selected machine identities are locked and credentials rotate.
The revoked launcher or agent can no longer authenticate as its former identity.
Human access today
The shipped boundary is the authenticated workspace account with session, CSRF, step-up, and server-side mutation enforcement. Multi-member seat roles and fine-grained team RBAC are not claimed as production capabilities on this page.
Portability today
Applications, execution, persistent paths, runtime caches, and full local ledgers remain customer-side. Workspace data, audit evidence, and proof packets can be exported. Active-active customer mirroring of the Infraveil control plane is not claimed.
Inspectability
What you can verify today.
Launcher and agent source installed on your machines.
Signed source hashes, release manifests, customer approvals, and active runtime versions.
Outbound network destinations through your own packet capture and firewall logs.
Local receipts, hash-chain continuity, queue state, rollout state, and rollback evidence.
Claims we do not make
Precision over theater.
Not a hosting provider. Your applications and compute remain on infrastructure you control.
Not Kubernetes in disguise. Infraveil owns its runtime contract and reconciliation model without requiring Kubernetes as a prerequisite.
Not an AI trust root. AI can propose or invoke bounded operations; signatures, policy, approvals, and machine verification remain authoritative.
Not externally audited yet. The inspectable mechanisms above are available now; a formal independent audit remains future work.
Production authority deserves scrutiny
Inspect the boundary before you trust it.
Use the demo, read the runtime source, inspect the release chain, and verify what leaves your machine.