One control plane for the entire infrastructure lifecycle
Infrapilot discovers what you run, models how it connects, and executes change against that model under policy you control. Four capabilities, deployed as one system, operated by one team.
Operating production estates at
A live model of everything you run
Automation is only as safe as the map it works from. Infrapilot builds and maintains that map itself — continuously, without agents, across every layer of the stack.
- Agentless discoveryNetworks, hypervisors, cloud accounts and clusters scanned on a schedule with no software to roll out first.
- Evidence-backed dependenciesEvery inferred relationship shows the traffic, configuration or query that produced it.
- Impact analysis on demandSelect any node and see precisely which services, teams and SLAs a change would touch.
Workflows that behave like production systems
Scripts fail quietly. Infrapilot workflows are durable, resumable and reversible, with the same guardrails applied whether a change touches one instance or twenty thousand.
- Visual and code, one objectAuthor on the canvas or in YAML. Both views edit the same definition and diff cleanly in Git.
- Rollback as a first-class pathEvery step declares its inverse. Rollback is rehearsed in lower environments, not written during an incident.
- Wave-based executionSequencing derived from real dependencies, with health gates between waves and automatic halt on regression.
Durable execution
A run survives control-plane restarts, network partitions and runner failure. It resumes from the last completed step rather than starting again.
Versioned as code
Every workflow, policy and runbook lives in Git. Changes arrive as pull requests and are reviewable as diffs.
Human tasks in-line
Approvals, manual verifications and business sign-off are steps in the workflow, not an out-of-band email thread.
Deterministic replay
Any past run can be replayed step by step with its exact inputs, which is what makes post-incident review tractable.
Guardrails that run before anything else does
Control is enforced at execution time, not reviewed afterwards. Policy decides what may run, where, by whom and in which window — and explains every denial.
- Zero standing privilegeCredentials are brokered per execution from your vault and expire when the step completes.
- Continuous control testingRegulatory and internal controls tested on a schedule, with evidence packaged for audit.
- Tamper-evident auditAppend-only, cryptographically chained records of every action, approval and output.
# Evaluated before any step runs
apiVersion: policy.infrapilot.io/v1
kind: ExecutionPolicy
match:
environment: production
assetClass: database
require:
- approvedWindow()
- riskScore(max: 40)
- verifiedBackup(within: 24h)
- preserveQuorum()
- blastRadius(max: 15%)
credentials:
broker: cyberark
ttl: 15m
onDeny: explain- Approved maintenance windowCW-2841 · 02:00–08:00 UTC
- Change risk below threshold18 / 100 (limit 40)
- Backup verified within 24h2,101 of 2,104 · 3 remediated
- Quorum preserved per wave38 availability groups
- Blast radius within limit238 of 2,104 per wave
- Credentials brokered just-in-timeCyberArk · 15 min TTL
- Production freeze not activeFreeze begins in 6 days
AI grounded in your estate, not the internet
Models are trained and prompted on your topology, your change history and your outcomes. Every recommendation shows its evidence, and nothing executes without an approval path.
- Risk scored from your historyChange risk modelled on comparable prior changes in your own environment, not an industry average.
- Runbooks drafted, humans approveCopilot writes the procedure and its rollback; an engineer reviews before it can run anywhere.
- Root cause with reasoning shownRanked candidates with the correlating evidence exposed, so engineers can confirm rather than trust.
Why did checkout latency spike at 02:14, and what should I do about it?
Checkout p99 rose to 4.8s at 02:14:08, against a 1.2s threshold. The most likely cause is stale statistics on four objects in pay-sql-01 following the index rebuild in CHG0048790 at 01:52.
- Query plans regressed on the four objects touched by the rebuild
- Connection pool saturation follows the latency rise by 40s — symptom, not cause
- Network path and consumer lag both flat through the window
UPDATE STATISTICS ... WITH FULLSCANEvery change carries a score, and the score shows its working
Risk is modelled from your own change history — how often changes of this shape, against this class of asset, in this window, have failed before. A number nobody can interrogate is a number nobody will trust, so each contributing factor is listed with its weight.
Policy consumes the score directly. Low-risk, well-precedented change can be pre-authorised; anything above your threshold routes to a human with the evidence already attached.
- Comparable prior changes4,206Strong evidence
- Failure rate in comparable set0.4%Low
- Blast radius238 of 21,662Contained
- Rollback rehearsed4h agoVerified
- Change volume in window3 concurrentNormal
Rehearse the change before it touches production
The knowledge graph is a model you can execute against. Run the workflow in simulation, see which assertions would fail, and fix the plan before the window opens.
Simulated execution
Every step runs against the modelled estate, producing the same wave plan, the same gates and the same predicted duration — without touching a host.
What-if analysis
Change a constraint — a shorter window, a node out for maintenance, a frozen region — and see how the plan reshapes before you commit to it.
Capacity projection
Model growth against current trend to find the month a cluster runs out of headroom, and raise the remediation as planned work rather than an incident.
Where each part runs, and what crosses the boundary
Infrapilot deploys as a self-hosted control plane or a dedicated single-tenant instance. In both models, runners live in your network, connect outbound only, and hold no long-lived credentials.
Access plane
How people and systems reach the platform
Control plane
Stateless services, horizontally scaled, no customer credentials at rest
Execution plane
Runners you deploy; outbound-only connections, no inbound firewall rules
Managed estate
Reached over native protocols — no agent required for discovery
What teams say after the first quarter
We were spending eleven weeks a quarter on database patching and still finishing late. The first automated cycle took six days, and the second took four. The difference was not speed of execution — it was that nobody had to negotiate a sequence any more.
The dependency graph paid for the platform on its own. We had four services nobody could account for sitting in the path of our signalling stack. Two of them were single points of failure.
Our regulator asked for evidence of control over privileged database access. Previously that was a six-week exercise across four teams. We exported it in an afternoon, and the auditors accepted it without a follow-up request.
Bring your hardest change window
The most useful proof of concept is the one your team is dreading. We will scope it, model it, and run it with your approvals in the loop.