Run releases, supervise processes, govern managed traffic, and use supported recovery controls.
Choose the operating workflow your team needs—from releases and service failures to scoped production access.
Practical tools and guides for teams running applications.
Learn about Infraveil, how the product works, and its security and data-handling practices.
Backend operations control plane
Operate your Linux fleet from one control plane. See which hosts and services need attention, choose where workloads belong, and send scoped operating actions. Local launchers and agents handle releases, supervision, managed traffic, and recovery—without an Infraveil application SDK.
Bring host capacity, service health, placements, and operating actions into one workspace.
The agent starts configured processes, checks health, applies managed gateway rules, and carries out supported recovery.
Your application stays an ordinary process on your Linux server. No Infraveil SDK is needed for supported supervised services.
From one host to the whole fleet
Running several servers is more than deploying the same application again. See host capacity and connection freshness alongside workload health. Choose a placement, drain a host from new assignments, or target an operating action without losing the service context.
Which services need attention, and is the host report current enough to act on?
Where should this workload be assigned, and which hosts have capacity?
What exactly will this command or maintenance action affect?
One operating workspace for the fleet. Local runtime control for each service.
Fleet operations
Compare host capacity, connection freshness, and workload health. Try a scoped command, a manual placement request, or a host drain—then drill into the service that needs recovery.
Inspect a host. Choose a workload. Keep the action scope visible.
| Host | Last report | CPU | Memory | Storage | Load / cores | Assignments |
|---|---|---|---|---|---|---|
| Current8 seconds ago | 68% | 72% | 54% | 2.4 / 4 | Open | |
| Current11 seconds ago | 24% | 38% | 42% | 0.9 / 4 | Open | |
| Stale4 minutes ago | — | — | — | — | Fresh report needed |
Drain stops new assignments. Existing services remain running until separately stopped.
Command scope: api-01 / Payments service
Placement is an operator request. Reported location and health do not change just because a new target is selected.
| Service | Release | Requested host | Reported host | Health |
|---|---|---|---|---|
| Payments service | 1.8.4 | api-01 | api-01 | Unhealthy |
| Catalog worker | 4.3.0 | api-01 | api-01 | Healthy |
| Identity | 3.2.8 | worker-02 | worker-02 | Healthy |
| Email worker | 2.1.6 | worker-02 | worker-02 | Healthy |
| Gateway | 2.14.1 | edge-03 | edge-03 | Last healthy · report stale |
Placement does not prove a healthy move or stop the previous process. Confirm reconciliation, service health, and any required source-host stop separately. Read the operating details
The release being tested in this failed-update example.
A separate request example: the configured gateway permits this request.
The new release failed its health check. The supervisor stopped its retry loop.
The recovery choice changes the running version and its health, not just the activity record.
Release control, process supervision, restart limits, and supported recovery belong to the same managed service. The result is checked at that service after the action.
Illustrative outcome. Actual recovery depends on configuration and workload compatibility; restoring code does not restore application data.
Five independently enrolled workloads, each with its service-level context. Controls update this example only and never call production APIs.
Capabilities
From fleet-wide context to service-level controls: choose an area to see what your team can do and what happens on your servers.
Fleet operations
Bring host capacity, connection freshness, and workload health into one workspace. Choose placement deliberately, drain a host from new assignments, and keep each operating action scoped to the intended host and workload.
How Infraveil works
The hosted control plane coordinates the requested operating state. The launcher manages local agents, and the agents run configured services, supervise health, govern managed routes, and carry out supported recovery.
Coordinates requested settings and receives reports from your servers.
Applies server settings and manages the service agents.
Checks updates, starts the service, and reports its health.
The application runs on your server, with its persistent files stored there.
Traffic + policy
A gateway routes requests to your services and applies the rules you configure. Follow an example request through the decision, response, and record. These controls cover traffic sent through that gateway.
Normal request example selected.
The new version failed its health check. Retries have stopped. Restore 1.8.3 below, or keep 1.8.4 while you investigate.
Recovery is an operating action
A deployment is not finished because a job says “done.” The local supervisor continues checking the process and its health. When the new version fails, it follows the configured restart limits instead of retrying forever.
Try the recovery choice in this example. Restoring the previous version changes what runs on the server, then checks whether that service is healthy. Keeping the current version does not restore it; it remains unhealthy and needs investigation.
Illustrative example—not a live production action. Restoring code does not reverse database migrations or restore application data.
The service after the action
The same managed service connects its release, process health, route policy, incident, and recovery action. Change the recovery choice above and see the running version and service result update together.
Use one operating layer for the release, running process, managed route, and supported recovery. Investigation and change history stay attached to that service.
Available records explain which managed action ran and what the server reported afterward. They do not guarantee application correctness or prove that one request caused a failure.
Security and data
Your applications run on your servers. Infraveil receives selected health reports, logs, and events. Some deployment options also store application source files with Infraveil.
| Responsibility / state | Hosted by Infraveil | Your infrastructure |
|---|---|---|
| Requested changes | Recorded in the dashboard | — |
| Requested settings | Sent to the server | Applied on the server |
| Launcher | — | Connects and manages the server |
| Service supervision | Selected health reports | Runs and monitors each service |
| Running applications | — | Customer-controlled |
| Persistent application files | — | Customer-controlled |
| Health and change records | Selected reports and optional local-record references | Full local record |
| Release-signing private key | Not held by Infraveil | Held by your team |
You can inspect the launcher and agent code on your servers. The hosted dashboard code is private.
Infraveil has not completed an independent external security audit. Published documentation and inspectable code do not replace one.
Workspace access uses an authenticated account. Confirm support with Infraveil before relying on separate permissions for individual team members.
Depending on your setup, Infraveil receives server status, service settings and health, selected logs and request records, security events, and records of managed changes. Some deployment options also upload application source files.
The application runs on your servers, where its working files, caches, saved data, and full local change record are stored. You retain control of the release-signing private key.
Connected tools
Operate releases, processes, managed routes, and recovery through the same service lifecycle. Connect relevant reports and alerts to specialist tools where their depth still matters.
Choose an area to see how it fits.
Prepare the selected package and run its configured install, build, and start steps.
Your team keeps its existing infrastructure and specialist tools.
Pricing
Professional includes two connected servers and five managed services. A service is an independently enrolled workload; it can contain configured APIs, workers, and other application processes.
Explore the dashboard and see how Infraveil would work with your applications.
