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
Infraveil operates the runtime beneath your applications: releases, processes, health checks, managed traffic, and recovery. One backend operations control plane across supported Linux servers—without adding an Infraveil SDK to your application.
Choose the service, release, routes, and operating policy from one hosted control plane.
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.
Why Infraveil exists
Deployment is one step. Your launcher and agents start and supervise configured services, apply gateway policies, enforce restart limits, and carry out supported recovery actions. Configure the operating layer around your application, not instrumentation inside its business logic.
Which service version should run, where, and with which commands?
Is it healthy, what happens when it fails, and when should retries stop?
Which rules apply to its managed route, and which recovery action can run?
Connect the work of running a backend—not just the dashboards describing it.
Capabilities
Choose an area to see what your team can do, what happens on your server, and what the dashboard reports.
Release execution
Select the service and release. The local runtime prepares its package and runs the configured install, build, and start steps under the selected release policy.
Inside the dashboard
Explore the same example service across its server, update, traffic, incident, and change-history views.
Compare what should be running with what each server reports.
| Service | Release | Server | Requested | Reported | Operation |
|---|---|---|---|---|---|
| Payments service | 1.8.4 | Primary server | running | degraded | Managed release |
| Identity | 3.2.8 | Server B | running | healthy | — |
| Catalog worker | 4.3.0 | Primary server | running | healthy | — |
| Gateway | 2.14.1 | Server B | running | healthy | — |
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.
Interactive example with sample data. The views show how information connects; they are not live product screenshots.
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 a separately managed part of an application, such as a payments API or background task.
Explore the dashboard and see how Infraveil would work with your applications.
