How Infraveil operates your backend.

Workspace: the customer operating scope. Launcher host: an enrolled server. Workload: an independently identified agent assignment and application package. Manifest service: one configured process or observed external service within that workload.

A host can carry several workloads; an agent can supervise several manifest services. A connected server does not by itself establish that every assigned application is healthy.

The hosted plane is not inherently an application-traffic proxy. In the managed request path, traffic reaches the gateway and application on the customer host. Selected observations then travel to the hosted plane.

The supported hosted implementation uses an application process with threaded concurrency and SQLite-backed operating storage. This architecture does not imply an active-active control plane, automatic cross-host failover or unlimited capacity.

The launcher reconciles its assigned workload roster with local agent processes. It identifies each agent with its workspace, launcher host and workload, starts the selected agent runtime and supervises that process. Host connectivity, assignment and runtime-update state are separate from application health.

Linux setup registers the launcher service using privileged installation steps and runs new automatic installations under the chosen non-root identity. Existing privileged installations need their own review; installation does not retroactively change their execution identity.

The agent verifies and extracts the selected package into a workload workspace, connects declared local persistent paths, prepares the service environment, executes configured install/build steps and starts the declared native processes. It captures application output, observes exits and performs configured local health checks.

This is process supervision under the host's permissions. It is not a VM or container sandbox and does not make an application or dependency safe merely by launching it.

Attachment is a different mode. A manifest-only package identifies an existing systemd service and permitted local observations. The agent can observe unit/process state, permitted journal output and configured health without taking over its deployment or restart ownership.

External-service definitions reject install, build and start commands. The existing service manager and your release process retain those responsibilities.

Manual: review a pending exact hash before signing. Exact-hash allowlist: hashes you previously approved may be signed without a fresh prompt. Automatic: sign pending hashes while enabled; this removes the per-release human review step.

These modes describe release signing. They do not grant every operating command or MCP action. Protecting the customer key and choosing the intended signing policy remain customer responsibilities.

A digest establishes byte equality; vendor signatures identify the expected release signer; a customer signature establishes approval of an exact hash. None establishes harmlessness, successful execution or correct application behavior.

Managed application-package replacement stops the existing owned services before starting the replacement. Do not plan this mechanism as a zero-downtime or blue/green application deployment.

Use this mode when the agent should prepare and own the application's process lifecycle. The package, start command, dependencies, permissions and health definition must fit the host. Required Node/native executables still need to be available; a declared runtime does not install every language toolchain.

Install/build commands use parsed arguments, rejected shell operators and bounded timeouts. Shell pipelines are not an unrestricted execution interface. A manifest version label is not by itself a promise of schema or migration compatibility.

Use attachment to observe a supported existing systemd service while its current owner continues deployment and process management. This can avoid application-source upload, but operational metadata and permitted observations can still leave the host.

The same dashboard vocabulary does not erase the mode boundary: a supervised managed process and an observed external unit have different supported controls.

App Logs show captured service stdout/stderr with service, runtime and stream context. This is the application's own output, distinct from supervisor diagnostics.

Runtime Logs describe launcher/agent activity such as synchronization, package handling, startup and process supervision. They help establish what the operating layer attempted and observed.

Request Trace covers observed application gateway traffic. Control Trace covers runtime-control traffic. Neither is a universal distributed tracing system or a raw-payload archive.

Operations, incidents, service catalog and fleet rollups combine received connectivity, health, runtime errors and supported traffic/security/pipeline events. Shareable status pages derive component state from those observations and have rotatable/revocable links.

Derived status is not independent external uptime probing. Incident grouping does not establish root cause or provide a complete human on-call/paging system. Stale, missing and dropped observations must remain visible as uncertainty.

Placement considers eligible hosts, labels, preferred region, workload-count limits, draining/stopping state, connectivity and external-service host affinity. Explicit rebalance and drain operations can have blocked or partial outcomes.

Moving a previously runnable workload requires its completed stop receipt and a fresh report from the original online host confirming that the workload is absent. Offline ownership cannot be transferred safely. An assignment updates desired ownership and the per-host roster; it does not migrate data or reserve CPU/RAM. Automatic cross-host recovery remains unavailable.

Configure supported placement, startup ordering and delays. Keep a host out of new assignments while planning maintenance. Select one workload or an explicit group for supported commands such as restart, stop, maintain, update and doctor. Host actions have their own supported vocabulary.

Inspect eligible targets, requested change and each reported result. Selecting rows, changing assignment and requesting a process command are distinct operations; a partial batch must not appear as universal success.

Host diagnostics and reported safe/burst capacity estimates help compare pressure and candidate placement. Workload allowances and count limits are not physical resource reservations or an admission-control guarantee. Validate memory, disk and dependencies for the actual application.

Configured health failures can recycle a managed process; exits then pass through the supervisor. Managed process exits consume a configured restart budget and apply delay. Exhausting the budget stops repeated retries and surfaces the failure. It does not repair an application bug or authorize a database restore.

The local encrypted, versioned, signature-checked package cache retains promoted known-good state. Candidate stability handling can promote the candidate, restore an available known-good package or stop. Recovery depends on available valid state and compatible application/persistent-data behavior.

Infraveil agent-runtime updates have candidate/previous slots, health windows and canary/batch progression. A rolled-back candidate halts progression for review. This updates the operating agent, not a customer's application through blue/green release traffic.

Declared local persistent paths reconnect selected files to the workload workspace across package replacement. They remain on the customer infrastructure. This is not replicated storage, a database-consistent backup or automatic data migration between hosts.

Verified local cache entries support package availability and known-good recovery. The cache is finite and needs disk headroom; missing, corrupt or incompatible entries can prevent recovery. A cached application package does not include an independent recovery copy of every mutable application file.

Local reporting queues and hosted history are bounded. Connection loss, pressure and retention/queue limits can delay or drop observations. Inspect backlog, drop counters, freshness and the available interval rather than assuming lossless capture or complete historical coverage.

The hosted plane persists selected account/configuration/operating records. Review applicable retention, redaction, residency, backup and deletion arrangements for the current offering; local execution does not mean no information leaves the host.

Supported changes use a preview/confirmation path tied to arguments, target scope, connection, current revision, impact and expiry. The connection policy chooses confirm-mode action authentication or explicitly authorized automatic actions; both retain scoped preview/confirmation and expiry. The adapter invokes the normal product handlers and middleware rather than creating a separate unrestricted shell.

A client does not receive the customer release-signing key through this interface. A prompt saying a human approved something is not itself a cryptographic attestation of that person's intent. Release approval and action confirmation remain separate controls.

Supported Slack, Teams, incident.io, GitHub and webhook event delivery requires enabled delivery and subscriptions. Paused delivery does not build a paused backlog. Pipeline analysis hooks are bounded configured hooks; hook responses are not arbitrary code or remote policy authority.

The reviewed product does not provide a working OpenTelemetry exporter or a built-in autonomous AI repair service. MCP gives an authorized client access to named product operations; it does not expand the runtime's authority.

Managed deployment can store uploaded application source and packages on the hosted side before verified delivery. The running processes and declared local persistent files reside on customer infrastructure. “No SDK in application logic” does not mean “Infraveil never receives source.”

Attachment can avoid uploading the existing application's implementation. It still sends the contract and permitted operational observations needed for the selected visibility. Review logs and reporting settings for secrets and sensitive application data.

The hosted plane receives selected configuration, machine identity, heartbeat, health, log and managed-traffic/control records. The customer-held release private key stays under the customer's control in the local approval flow; hosted verification data and release signatures serve a different purpose.

Protect local credentials and release keys, review automatic approval deliberately and plan offboarding/revocation. A record of revocation cannot make a disconnected host immediately observe it.

Your team retains infrastructure accounts, OS hardening, application correctness and authorization, dependencies, secrets, persistent-data protection, public exposure/TLS, database backups and business continuity. Decide who may request powerful actions and how the release key is protected.

Confirm workload compatibility, required host executables, health semantics, available storage and recovery candidates. Fine-grained enterprise RBAC, SAML/SCIM, multiparty approval, active-active management and full air-gap operation are not implied by this architecture.

1. Connect a supported test host and identify its launcher, workload and manifest services.
2. Exercise the intended release-signing mode and distinguish pending approval from execution.
3. Inspect app output, runtime diagnostics, configured health and gateway decisions for the same workload.
4. Try one supported scoped command, then compare requested and reported results.
5. Exercise restart exhaustion, a compatible known-good package and agent-runtime rollback in an authorized test environment.
6. Interrupt control-plane connectivity and observe local continuity, stale hosted views and reconnection.
7. Test persistent-data backup/restore separately and review queued/dropped observations.

These are evaluation steps, not a claim that a particular customer's environment has passed them. Implementation descriptions establish mechanisms; scenario receipts establish behavior only within their tested scope.