Architecture Overview
Autoheal runs as three tiers:
- an always-on control plane that holds your data and orchestrates agents,
- long-running runners that host execution, and
- ephemeral sandboxes where tool commands actually run.
The same three tiers exist whether you run Autoheal as SaaS or in your own cloud (BYOC); only where they run changes. This page describes what each tier is for and what it stores, then the two deployment models.
The three tiers
The diagram below shows the three tiers as they run today in Autoheal's SaaS — on Amazon EKS in Autoheal's AWS account. BYOC runs the identical architecture in your own account; the only differences are whose account it is and public vs. private ingress (see Deployments).
Users reach the always-on control plane over SSO through a public, SSO-gated load balancer. The control plane (on EKS) holds all durable state and dispatches work to a long-running runner, which hosts ephemeral sandboxes that run tool commands read-only against your systems and write results back. Inference is routed to the model provider best suited to each task — some in-account, some direct. The application, runner, and all your data sit inside Autoheal's AWS account, isolated per tenant.
The runner is a deliberate boundary — the code that executes commands against your environment never sits alongside the services that hold your durable state.
| Tier | Lifecycle | Runs | Stores |
|---|---|---|---|
| Control plane | Always on | Web UI, API, agent orchestration, identity, workflow | Everything durable — investigations and run traces, agent specs, memories and skills, the Engineering Context Graph, users and roles, audit logs, integration config. PostgreSQL is the system of record; object storage holds artifacts; Redis is a transient cache/stream; secrets in a dedicated store. |
| Runner | Long-running, autoscaled | Sandbox lifecycle, scoped-credential brokering | Transient only — cached repos and working files, reaped automatically. No system of record, no database. |
| Sandbox | Per run, inside a runner | Tool commands: CLIs, kubectl, MCP tools | Nothing durable — filesystem destroyed at cleanup; outputs written back to the control plane. |
Terminology. An investigation is the durable unit of diagnostic work for one issue — an alert, an incident, or a question you pose; it may execute over one or more runs (the first run plus any later resume or follow-up). Each run gets one sandbox, created when the run starts and destroyed when it ends, so an investigation uses one sandbox at a time and a fresh one on each resume — never many at once. One runner hosts many sandboxes over its life.
Data flows
Where the platform runs differs by model: in SaaS the control plane runs in Autoheal's account, so your data flows out to it (SSO-gated, isolated per tenant); in BYOC it runs in your account, so most data never leaves. What's constant is how the agent touches your data and what paths exist into the platform:
| Traffic | Direction | Destination / source | Carries |
|---|---|---|---|
| LLM inference | Outbound | The model configured for your deployment — an Autoheal-supported provider, in-account (Bedrock / Azure OpenAI / AI Foundry) or direct (OpenAI / Anthropic) | Prompts and context: investigation and alert context, tool output, and excerpts of the data the agent reads |
| Integration reads | Outbound | Your observability, code, cloud, and database endpoints | Read-only queries and their responses |
| Alert ingestion | Inbound | Your monitoring (Alertmanager, Dynatrace, …) posts to an authenticated webhook | Alert payloads: labels, annotations, severity |
| User access | Inbound | Your users' browsers, SSO-gated | Sign-in and app requests |
The agent's access to your systems is outbound and read-only, and every inbound path is authenticated and configured by you. In BYOC all of this stays on private networking with no public inbound — and with an in-account model and in-network integrations, nothing leaves your account at all (see What leaves your environment).
Durability and failure handling
Both the investigation and the sandbox lifecycle run as durable Temporal workflows whose state lives on the control plane, not on any single runner. A runner is disposable: if one is terminated mid-run, the workflow re-places the sandbox on a surviving runner and rebuilds it from spec (repositories re-cloned, init re-run). A command that was in flight when the host was lost is not silently retried — because its outcome is unknown, it is marked indeterminate and the agent decides whether to re-run it. Re-placement is bounded (a few attempts); past that the run is marked failed rather than retried forever. Nothing durable lives on the runner, so losing one costs a rebuild, not data.
Deployments
Autoheal offers two deployment models: SaaS, or BYOC — the same three tiers, either in Autoheal's account or in your own.
Autoheal works with your team on account, network, and compliance specifics before the first install.
| SaaS | Self-hosted BYOC | |
|---|---|---|
| Runs in | Autoheal's cloud account | Your cloud account |
| Data at rest | Autoheal's account, isolated per tenant | Your account and region |
| LLM inference | Autoheal-managed | The provider you choose (in-account or direct) |
| Upgrades | Automatic | You control the window |
| Best for | Fastest start; most teams | Data residency or contractual requirements that keep data in your account |
SaaS
- Runs in Autoheal's own infrastructure; you access it in your browser over SSO.
- Connect your tools as integrations, then start building agents and running investigations.
- Autoheal hosts, operates, and upgrades everything — there is nothing for you to run.
- Your data is logically isolated per tenant.
- Most teams should start here.
This is exactly the deployment shown in the diagram above: the three tiers running on Amazon EKS in Autoheal's AWS account, with public SSO-gated ingress and outbound read-only access to your environment.
BYOC
For customers with strict security and data-protection requirements, Autoheal offers a BYOC deployment:
- Runs on Amazon EKS or Azure AKS, inside your own Kubernetes cluster — a single-tenant, shared-nothing installation.
- The application, orchestration, identity, and all data stay entirely within your cloud account.
- Connections to your data sources flow over private, encrypted network paths.
- There is no public inbound — no Autoheal-hosted service reaches into your environment at runtime.
BYOC runs the same three tiers, the same skeleton as the SaaS diagram above — but the whole box is your account: ingress is private with no public inbound, and your data never leaves your account. You can run every install and upgrade yourself; if you'd rather Autoheal operate it, you grant a scoped, revocable role it assumes only for the install window. Either way Autoheal keeps no standing access. See BYOC for the full AWS (EKS) and Azure (AKS) topology.
Who does what — your platform team provisions and manages the cloud infrastructure (cluster, network, managed data, IAM); Autoheal deploys, operates, and upgrades the application.
Get started
Both models start with a conversation — reach us at autoheal.ai or support@autoheal.ai.
- SaaS — we set up your tenant and connect your tools; your team runs investigations in the browser.
- BYOC — onboarding covers sizing for your load, the network and egress allowlist, your LLM and identity configuration, and the install, run together with your platform team.