Ground
Truth.

ActivLayer lets you describe infrastructure tasks in plain English — "restart the API gateway in production", "check which pods are failing in the staging cluster", "find all EC2 instances not tracked in Terraform" — and executes them safely on your real infrastructure.

It plans the steps, checks them against your policy rules, optionally pauses for human approval, executes, and gives you a plain-English summary of what happened.

Monitoring tools observe your infrastructure and alert you. ActivLayer acts on it. The two are complementary: your monitoring tools fire the alert, ActivLayer receives it, diagnoses the issue, and either resolves it autonomously or brings a fully-formed action plan to your on-call engineer for a single-click approval.

You keep your existing monitoring stack — ActivLayer sits at the response layer, not the observation layer.

Runbook automation tools execute pre-written scripts triggered by predefined conditions. ActivLayer reasons about what to do based on the current state of your environment — it can handle incidents it's never seen before. If a pod crashes for a reason your runbooks don't cover, ActivLayer analyzes the logs, proposes a fix, and executes it.

That said, ActivLayer also ships with 30+ pre-built runbooks and can ingest your existing ones into its knowledge base — so it learns from your documented procedures and applies them intelligently.

The platform uses a multi-stage pipeline — not a single "ask the AI to do stuff" prompt. Every action goes through:

The AI generates the plan; the policy layer enforces the guardrails; humans stay in the loop for anything high-risk. The scenarios on this site are drawn from real executions with real log outputs and real session IDs — not demos built for the website.

Three core profiles — each with a distinct operational need:

Three independent layers — any one of them can block an action:

These layers work independently. If the AI proposes something your policy doesn't allow, it's blocked even if the risk level is LOW.

HITL is an approval gate that pauses execution before the platform acts. When an operation hits a HITL gate, the engineer gets a notification showing:

• What the platform detected and why it flagged it
• The AI's full reasoning about what's happening
• The exact steps it plans to execute, with the specific commands
• Approve or Deny — one click, complete context

Unapproved plans that time out cancel automatically — there's no risk of a stale approval executing hours later. HITL is configurable per agent, per environment, or per severity level.

Yes. Each agent is defined by a template that specifies:

• Which environments it can access (e.g., staging-* only, never production)
• Which execution channels it can use (reads and deletes only — no Terraform, no Ansible)
• Command deny patterns (regex rules that block specific commands regardless of what the AI plans)
• A daily action budget (max number of operations per day — prevents runaway automation)
• Autonomy level (full autonomous / HITL always / HITL for high-risk only)

An agent authorized only to read Kubernetes state can never execute a Terraform destroy — even if the AI decides it's a good idea.

The AI can make an incorrect plan — that's why the policy layer and HITL gate exist. If the plan passes policy checks but turns out to be wrong in practice, the platform includes a self-correction loop: if an execution step fails, the platform analyzes the error, generates a corrected approach, and retries up to a configurable limit.

If the correction loop is exhausted, the session fails gracefully and logs the full trace so you can see exactly what was attempted and why. Nothing executes outside the logged session model — every action is fully auditable.

Only if you configure it to. For ALERT severity events with an agent configured for autonomous execution, yes — it will act and log everything. For INCIDENT or higher severity, the default requires human approval. You control the threshold.

You can configure Slack or webhook notifications for every autonomous action, so your team always knows what ran — even if they didn't have to approve it. The complete audit trail is in the Operations dashboard.

Yes. Any running session can be cancelled from the Operations dashboard or via the API. You can set agents to inactive to immediately stop processing new events. For environments where you want to pause all automation, maintenance mode logs all events but executes nothing — every dispatch is held until you re-enable.

Additional platforms are added via the connector framework. Enterprise customers can request custom connectors.

Yes. ActivLayer connects to OpenShift clusters via the standard Kubernetes API — OpenShift is API-compatible. OpenShift-specific resources (Routes, DeploymentConfigs, BuildConfigs, Projects) are supported via the OpenShift API extension. The scenarios on this site include a real OpenShift canary rollback example.

If you're running OpenShift on-premises, airgap deployment means no traffic leaves your network.

Yes. ActivLayer does not replace your existing playbooks or modules — it uses them as execution primitives. You point it at your Ansible inventory and playbook directory; when it decides Ansible is the right tool, it runs your playbooks with the appropriate parameters. The same for Terraform: it operates against your existing state files and modules.

Your IaC continues to be the source of truth. ActivLayer is the layer that decides when to run it.

Slack and webhook integrations are available now for HITL approval notifications and autonomous action notifications. PagerDuty integration (receive incidents, acknowledge, resolve) is on the roadmap. Jira integration (create tickets from failed sessions, link resolved sessions to issues) is available in Enterprise.

ActivLayer does not store credentials in plaintext. Credentials (kubeconfigs, API keys, cloud credentials) are encrypted at rest and optionally managed through HashiCorp Vault integration — in which case ActivLayer only holds a Vault token, never the credential itself. In airgap deployments, all credential storage stays within your network. We do not have access to your credentials.

It depends on your deployment mode:

If data residency or airgap is a requirement, the on-premises deployment is the right choice.

Yes. Airgap mode is a first-class deployment option. It replaces the cloud AI model with a self-hosted model running inside your Kubernetes cluster — no external network calls at inference time. It requires a GPU node (or CPU with sufficient memory), but otherwise behaves identically to the cloud deployment. Available in Professional and Enterprise editions.

We are currently pursuing SOC 2 Type II certification. The platform's architecture is built with SOC 2 control requirements in mind: role-based access control, full audit logging, encrypted credential storage, configurable HITL approval gates, and immutable session records. If SOC 2 compliance documentation is a procurement requirement, contact us — we can provide our current security posture documentation and controls inventory.

The platform runs with a scoped service account inside your cluster. The default RBAC profile allows: read/list/watch on pods, deployments, services, events, configmaps; create/delete on pods; update on deployments. You customize this — a read-only agent only needs get/list/watch verbs. ActivLayer does not require cluster-admin. The RBAC manifest is provided as a Helm template that you review before installation.

The platform installs via Helm in under 10 minutes on any Kubernetes cluster. From a fresh install to running your first intent: typically under 30 minutes if you have a cluster and an API key ready. The onboarding wizard guides you through connecting an environment, seeding the runbook library, and creating your first agent in 5 steps. No professional services engagement required.

No. For Kubernetes, ActivLayer runs inside the cluster as a standard deployment — no per-node agents. For Ansible, ActivLayer calls Ansible from the orchestrator using your existing inventory — no agent on managed hosts. For VMware and Proxmox, it connects via their management APIs. The only requirement is that the ActivLayer orchestrator pod has network access to the relevant APIs.

No. ActivLayer ingests your existing runbooks (Markdown, Confluence pages, plain text) into a vector knowledge base and uses them to inform how it plans responses. Your Ansible playbooks run unchanged. Your Terraform modules run unchanged. The platform adds the intelligence layer on top of what you already have — it doesn't require you to migrate or rewrite anything before you can start.

Yes. The Community edition is free: 1 environment, up to 3 agents, fully functional with no time limit. HITL approvals, OPA policy, Kubernetes integration, audit trail — all included, no credit card required. Upgrade to Professional or Enterprise when you need more environments, airgap mode, or SSO.

Yes — contact us for a guided trial with full Professional or Enterprise features enabled for your environment. We typically run a 2-week trial with an onboarding session to connect your first real environment and configure your first agents. The goal is for you to see ActivLayer act on real events in your infrastructure, not a sandboxed demo.

Pricing is based on the number of managed environments and active agents. We don't charge per incident resolved, per API call, or per execution — so there's no disincentive to automate. Contact us for a quote based on your environment scale.

Yes. Each client's environments, agents, credentials, policies, and session history are isolated. In the Enterprise edition, you can configure role-based access so client-specific operators only see their own environments, while your platform team has visibility across all clients simultaneously.

White-labeling and OEM arrangements are available for Enterprise customers. The platform has a full REST API, so client-facing dashboards can be built on top of ActivLayer's data without exposing the ActivLayer UI directly. Contact us to discuss your requirements.

Yes. OPA policy rules are configured per environment, not globally. A PCI-DSS client can have stricter rules (all production changes require HITL, all sessions logged to an external SIEM) while a less regulated client runs more permissively — all managed from the same platform instance. You can also create per-client agent templates with different authorization scopes and command restrictions.

Session reports — which actions were taken, when, by which agent, with what approval, and what the outcome was — are available via the API and Operations dashboard export. These are suitable for change management records, security audit evidence, and compliance reporting (SOC 2, ISO 27001, PCI-DSS). Auto-generated DR drill reports include RTO/RPO metrics, resource inventories, and approval audit trails formatted for board-level or auditor review.