Backend operations, from one app to the fleet.

See launcher hosts, assigned workloads, connection freshness and received operating state in the same workspace. Move from a fleet view into one application without losing its host, release or incident context. The service catalog keeps the inventory connected to the work you operate.

A registered host is not necessarily connected, and a connected launcher does not prove its applications are healthy. Use the reported application health and the age of its observation when choosing a target.

Read the operating guide ↗

Create a server identity, get its private setup command, and run it on your supported Linux host. A launcher connects that host to the workspace and starts its assigned workload agents. Each agent operates the manifest services belonging to its workload.

The host supplies compute, application runtimes and permissions. Enrollment and customer-held release approval are separate controls; generating a command does not mean the server is connected.

Read the operating guide ↗

Use host labels, preferred region and workload-count settings to plan assignment. Set host/workload order and startup delays, drain a host from new assignments, or request an explicit rebalance. Target one workload, a selected group, or a supported host action, then inspect requested changes and returned results separately.

Moving a previously running workload requires a completed stop and a fresh original-host report confirming its absence. Observed systemd services stay host-bound. Placement does not migrate persistent data or provide automatic cross-host failover.

Read the operating guide ↗

For managed applications, the local agent prepares the approved package, runs configured install/build/start steps, captures output and watches service exits. Configured local health checks show whether a process is actually responding. Restart budgets and delays prevent an ordinary crash from becoming an unbounded restart loop.

Supervision uses native processes on the customer host. The runtime and health path must fit the application; this is not a container sandbox or a guarantee about every business operation.

Read the operating guide ↗

An infraveil.json runtime contract describes services, working directories, startup commands, environment, local ports, health checks, routes and declared persistent paths. A workload can contain several compatible services, including different runtimes. No Infraveil SDK needs to be embedded in their application logic.

The host still needs the relevant executables and dependencies. Declared persistent paths preserve selected local files across package replacement; they are not replicated storage or a database backup.

Read the operating guide ↗

Managed deployment packages the configured application and lets the local agent own its supported process lifecycle. Existing-service attachment instead describes a running systemd service so you can inspect its process, permitted journal output and health, with optional configured gateway routing.

Attach does not take over that unit’s deployment or restart policy. Managed uploads may include source on the hosted side; a manifest-only attach avoids uploading the application implementation. Choose the mode that matches the responsibility you want Infraveil to take.

Read the operating guide ↗

Roll out eligible Infraveil agent-runtime updates through canary and batch progression with health windows. The launcher tracks candidate and previous runtime slots; an unhealthy candidate can roll back locally and halt further progression for review.

Runtime rollout is distinct from replacing a customer application package. App replacement stops its owned processes and needs compatible configuration and data; it is not a zero-downtime or database-rollback promise.

Read the operating guide ↗

Filter App Logs by workload, service, stream, level or text to inspect application output. Runtime Logs show supervisor and control activity. Request Trace follows received managed-gateway observations; Control Trace explains communication with the operating runtime. Keep the failing application and its server identity in view throughout the investigation.

These are bounded received observations, not universal distributed tracing or a raw payload archive. Missing, stale or dropped reports remain visible limitations of the investigation.

Read the operating guide ↗

Operations groups received application, connection, traffic, security and runtime problems into incidents. Use the service catalog to locate ownership and the fleet context around an affected workload. A shareable status page gives others a derived component-health view, with a public link you can rotate or revoke.

Derived status reflects what the system has received. It is not an independent external uptime probe or a human on-call scheduling and paging service.

Read the operating guide ↗

Inspect reported host resources, capacity diagnostics and workload placement context. Follow cached package candidates and promoted known-good state, along with delivery queues and dropped-report indicators. These views help distinguish a failing app, resource pressure and delayed reporting before acting.

Capacity values are estimates, not reserved CPU/RAM or a scale benchmark. Package cache supports local recovery; it is not an off-host backup, replicated application data or lossless telemetry.

Read the operating guide ↗

Declare routes that forward configured gateway requests to the appropriate local manifest service. The runtime can evaluate the applicable policy before forwarding an allowed request, then report selected request and decision context for that workload.

Traffic must traverse the configured gateway for those controls and observations to apply. Customer DNS, public TLS, host firewalling, direct-port exposure and upstream edge protection remain part of the deployment design.

Read the operating guide ↗

Configure workspace policy and workload overrides for supported WAF modes and rules, rate limits, IP/CIDR and geographic controls, method/body constraints and honeypot routes. Review effective settings and received decisions to understand what was allowed or rejected at the managed request path.

Coverage follows the configured route, engine and inspection limits. It does not extend to bypass traffic or saturated upstream links. Review honeypot behavior and other controls in the deployed mode before relying on them operationally.

Read the operating guide ↗

Configure declarative telemetry and response stages around managed traffic, then inspect pipeline decisions and logs together. Use the resulting bounded analytics to understand which configured stages ran and how they affected a request, rather than treating every security event as an isolated alert.

Analysis hooks and pipeline stages have a defined contract. They do not give an external model arbitrary code execution or authority to rewrite production policy through its response.

Read the operating guide ↗

Create a named, expiring MCP connection for a supported client, select read-only or control access, and run its generated setup command on the AI client’s computer. Named tools cover inventory, logs, policies, pipelines, source/deployment operations, placement and supported workload or host commands.

Changes retain scoped target previews, one-use confirmations, workspace authorization, expiry and revocation. The connection’s approval policy controls per-action prompts; it does not grant a general shell, billing changes, account authentication changes or your release-signing key.

Read the operating guide ↗

Review named runtime/application releases with the customer-held signing key and the configured release policy. The local software checks delivery before execution. Release and command history connect the requested change with its target, reported execution and later health, supporting day-to-day operational decisions.

Approval, dispatch, execution and healthy result are separate states. A signature authenticates the approved artifact; it does not establish that all application behavior is harmless or that persistent-data changes can be undone.

Read the operating guide ↗

Configure supported event delivery to Slack, Teams, incident.io, GitHub or an approved webhook destination, with the subscriptions you need. Export retained workspace, runtime, traffic and security information through sanitized customer exports; MCP can browse supported export sections in bounded pages.

Delivery must be enabled and subscribed, and paused delivery does not build a replay backlog. The OpenTelemetry endpoint reference is not a working OTLP exporter. Exports remain subject to retention and redaction limits.

Read the operating guide ↗

Use account factors and action authorization, workspace preferences, billing/usage and purchased capacity, support, feedback and documentation alongside the operating controls. Keep the server, workload and manifest-service terms clear when planning capacity or asking for help.

Current plan prices and allowances are explained on Pricing. Support surfaces do not create an unconditional response SLA, and account controls do not imply SAML, SCIM or enterprise team RBAC.

Read the operating guide ↗