The platform
One Platform. Connected Operations.
StackHeal sits between the systems that generate operational work and the systems that do it. One engine carries a request through interpretation, policy, execution and verification — and records what happened.
- Interpretation proposes, policy permits, verification confirms
- Registered actions only — no general-purpose shell
- Hosted or self-hosted execution runners
Workflow canvas · wf.disk_reclaim.v3
What connects
Five systems, one run.
Customer support, infrastructure resources, monitoring signals, automation workflows and verification meet in one place instead of being stitched together by people moving between consoles.
StackHeal
Connects every system below
- Customer supportTickets and requests
- Infrastructure resourcesHypervisors, clouds, servers
- Monitoring and alertsMetrics, alerts, incidents
- Automation workflowsPlaybooks and approvals
- Verification and visibilityOutcome checks and audit trail
How it fits together
Six layers, from a request arriving to an outcome recorded.
Deliberately described in plain terms. The engineering detail lives in the documentation.
- 01
Intake and triggers
Webhooks, monitoring alerts, ticket events, schedules, API calls and manual runs. Every payload is normalised and bound to a tenant, environment and asset scope before anything executes.
- Service desk events
- Monitoring alerts
- Schedules
- REST API
- Manual runs
- 02
Interpretation
Where input is unstructured, AI reads the request, resolves intent, correlates signals and matches runbooks — producing a structured proposal with a confidence score. It proposes; it never permits.
- Intent classification
- Signal correlation
- Runbook matching
- Response drafting
- 03
Policy and approvals
Deterministic evaluation in code: who may do what, on which assets, in which environments, up to what blast radius, requiring whose sign-off. This layer is the control boundary.
- Entitlement rules
- Blast-radius limits
- Maintenance windows
- Named approvers
- 04
Workflow engine
Versioned definitions composed of conditions, actions, approvals and verification assertions. Retries resume rather than duplicate. Nested workflows let you build a library of reusable operations.
- Conditional branching
- Typed inputs
- Idempotent steps
- Nested workflows
- 05
Action catalogue and execution
Registered operations with typed inputs, resolved credentials and declared blast radius. Runners execute them against your systems — hosted by StackHeal or deployed inside your network.
- Platform APIs
- Ansible
- Registered scripts
- HTTP actions
- Private runners
- 06
Verification and run history
Outcomes are asserted against measured state, then recorded append-only: inputs, outputs, branch decisions, approvals, timings and the workflow version that ran.
- Outcome assertions
- Immutable records
- Per-tenant reporting
- Audit export
What is not implemented in this website
Deployment
Run it where your constraints require.
The control plane and the execution runners are placed independently, which is what makes the platform workable for teams with network or residency requirements.
StackHeal cloud
Control plane and runners hosted by StackHeal. Your systems are reached over authenticated outbound connections. Simplest to operate.
Best for: Teams whose platform APIs can be reached from a managed network path
Private execution runners
Control plane hosted; runners inside your network. Credentials and command execution never leave your environment, and no inbound firewall rules are required.
Best for: Providers widening automation across sensitive systems
Self-hosted
Control plane and runners both in your environment. Used where residency, air-gapping or compliance make a hosted control plane unsuitable.
Best for: Regulated industries and strict residency requirements
Controls
The boundary is architectural, not advisory.
Operations automation holds credentials to the systems that matter most. These limits are enforced by the platform rather than requested in a prompt.
Registered actions only
Workflows compose from a catalogue you control. There is no general shell, and a run cannot introduce a capability that was not registered.
Separation of duties
Authoring, publishing, running and approving are distinct roles. Holding both halves of a pair removes the control, so the model makes that visible.
Server-side secrets
Credentials are referenced by name and resolved by the runner at execution time. They never enter a definition, a run record or a model context.
Versioned definitions
Workflows are versioned, diffable and revertible, and every run records exactly which version executed.
Products
What you build on it.
Each product is a set of workflows, actions and policies for a particular kind of operations work — all running on the engine above.
- AI Support AutomationTurn incoming support requests into structured, actionable workflows.
- VM ProvisioningStandardize virtual machine provisioning and infrastructure lifecycle operations.
- Backup AutomationCoordinate backup jobs, monitor outcomes, and simplify recovery procedures.
- Infrastructure MonitoringConnect monitoring signals with troubleshooting and approved remediation workflows.
- Server OperationsRun recurring server and facility tasks the same way every time, with a record of each run.
- Workflow OrchestrationConnect systems and automate repetitive operational processes.
- IntegrationsBring support, monitoring, and infrastructure systems together.
Why it matters
Fewer disconnected processes. Better visibility. More consistent execution.
The handoffs disappear
Relaying context between a ticket, a console and a monitoring dashboard becomes steps in one run rather than a person switching tabs.
One place to look
What ran, on which asset, under whose approval, verified or not — answered from a single run history instead of reconstructed.
Consistency that survives growth
Adding a customer, a site or a platform means new policy rather than a new procedure, so the estate stays describable.
Platform questions
Something not covered here? Ask our team.
See the platform against your own workflows.
Bring two or three request types your team handles manually today. We will walk through how each would be built, where the approvals sit, and what the run history records.