SuperPlane: Open-Source AI Factory Brings Deterministic Control to Agent Chaos

AI Speed Exposes Approval Bottlenecks

Over the past year, AI agents have accelerated code production to the point where a single day's output matches a week's worth of pull requests. The bottleneck is no longer writing code but the downstream steps: who approves changes, whether CI passes, whether to pause deployments off-hours, how to roll back a canary within 30 seconds, and who triages logs and metrics during incidents. Teams have relied on fragile Bash scripts, complex CI YAML, and manual Slack monitoring — approaches that become rubber-stamp approvals or let agents bypass guardrails entirely.

What Is SuperPlane?

SuperPlane is an open-source automation engine written in Go (backend) and React (frontend), licensed under Apache 2.0. It positions itself as the control plane for AI-driven engineering , letting teams orchestrate Git, LLMs, CI/CD, observability, incident response, and infrastructure into deterministically executed engineering workflows with guardrails for both humans and AI.

Language: Go + React

License: Apache 2.0, fully open source

Status: Beta — core primitives and integrations still evolving; breaking changes possible

Deployment: Self-hosted (Docker Compose, Kubernetes) or managed SuperPlane Cloud

Community (at publication): 7k+ GitHub stars, 600+ forks, active Discord

Four Building Blocks of an App

The core abstraction is an App — a deployable unit that bundles workflow, console UI, state storage, and execution logic, all versioned in Git. Each App consists of four components:

Canvas — Visual workspace for designing and running workflows as a graph of nodes and subscriptions

Console — Human-facing dashboard that turns workflow state into KPIs, charts, and clickable runbooks

Memory — App-level persistent JSON store shared across runs, also driving Console visualizations

Files — Git repository holding canvas.yaml, console.yaml, scripts, and any other files — enabling true configuration-as-code

Together they form a mini operational system with its own UI, state, and full version history , not just a throwaway script.

Event-Driven Deterministic Execution

Canvas nodes are either triggers (e.g., GitHub push, PagerDuty event) or components (e.g., deploy service, send Slack, wait for approval). Nodes connect via subscriptions; an incoming event traverses the graph, creating a Run . The key design is durable execution : every Run, Run Item, and Payload is persisted. If the server crashes, failed steps resume from the exact breakpoint without custom retry logic. This state-machine approach fundamentally distinguishes a control plane from brittle scripts or CI pipelines.

A single Canvas can host multiple independent workflows and support concurrent Runs — hence the "factory" metaphor rather than a simple conveyor belt.

Built-In Dual-Persona AI Agent

Each App includes a Claude-powered agent with two strictly separated modes:

Build Mode (Write)

Add, remove, or rewire nodes and connections

Swap components (e.g., replace Claude with OpenAI) and auto-reconnect downstream references

Write Console panels, scripts, and stash changes

For complex requests, the agent first proposes a Rubric (construction plan) awaiting human confirmation before acting

Can only stash changes — never commit directly

Ask Mode (Read-Only)

Inspect recent run records, read node payloads, view queues

Cross-reference data sources, e.g., "Which services deployed in the 10 minutes around this alert?"

Generate charts and statistics inline, such as latency distribution across the last 50 production deployments

Permissions are fully inherited from the user's session RBAC — the agent cannot do anything the user cannot, and cannot cross App boundaries.

Runners: Where AI Does the Heavy Lifting

When built-in components don't cover a specific action, a Runner node executes custom logic on dedicated machines:

Execution modes: Shell, Bash, JavaScript, Python

Environments: Host (bare metal) or Docker (custom image)

Machine specs from e1-tiny (0.5 vCPU / 1 GB) to e1-large (4 vCPU / 16 GB), both AMD64 and ARM64

Inter-step data passing via $SUPERPLANE_RESULT_FILE or returning a JSON object

Critically, Runner images come pre-installed with Claude Code, OpenCode, Codex CLI, plus git, gh, jq, docker — a clear signal the platform is purpose-built for scheduling AI coding agents, not merely wrapping CI.

Ecosystem Integrations: The Entire Engineering Loop

SuperPlane's component library spans:

AI/LLM: Claude, OpenAI, Cursor, Perplexity, OpenRouter

Version Control / CI/CD: GitHub, GitLab, Bitbucket, CircleCI, Harness, Semaphore, Octopus Deploy, Render

Cloud & Infrastructure: AWS (ECR, Lambda, CloudWatch, SNS), GCP, Azure, OCI, DigitalOcean, Hetzner, Cloudflare, Coolify

Observability: Datadog, Grafana, Honeycomb, New Relic, Prometheus, Sentry, Elastic

Incident Response: PagerDuty, Incident.io, FireHydrant, Rootly, Statuspage

Collaboration: Slack, Discord, Teams, Telegram, SendGrid, SMTP

Ticketing: Jira, ServiceNow, Linear

Virtually every tool in a modern engineering stack can be dragged onto the canvas as a trigger or action.

Real-World Scenario: Canary Deployment Workflow

The canonical example is a 10% → 50% → 100% canary release . Once modeled, the flow becomes versioned, visual, and auditable : every step's inputs/outputs (Payloads) are inspectable, failures pinpoint the exact node, and rollback paths are explicit branches in the graph — not tribal knowledge.

Other documented patterns include:

PR Preview Environments: Spin up ephemeral environments on PR creation, run tests, post access link back to the PR

Policy-Gated Production Releases: Auto-pause off-hours; require on-call + product approval before deploy

Multi-Repo Release Trains: Wait for all service builds to finish, then orchestrate a single coordinated release

"Golden 5 Minutes" Incident Response: Parallel fetch of recent deployments and health signals, auto-generate evidence package, open ticket

Quick Start

Run the demo locally in seconds:

docker pull ghcr.io/superplanehq/superplane-demo:stable

docker run --rm -p 3000:3000 -v spdata:/app/data -ti ghcr.io/superplanehq/superplane-demo:stable

Open http://localhost:3000 to explore the built-in example Canvas. Production deployment options include single-node Docker Compose, Kubernetes (GKE/EKS), or the managed SuperPlane Cloud.

How It Differs from n8n, Airflow, Temporal

Engineered for engineering workflows: Native integrations target Git, CI/CD, observability, incident response — not generic marketing automation or data pipelines.

Apps, not just Workflows: Each App ships a customizable Console UI and persistent Memory, producing an operational tool with an interface, not a fire-and-forget pipeline.

AI as a first-class citizen: Built-in agent, purpose-built Runner images pre-loaded with coding agents, and LLM components are foundational design assumptions, not afterthought HTTP wrappers.

Closing Thoughts

SuperPlane remains in Beta with expected breaking changes — a factor for any production adoption decision. However, it addresses a pressing systemic problem: when AI agent throughput far outpaces human review capacity, teams need a rule system that both humans and AI must obey, with built-in traceability, gates, and rollback . That is why it earns the "AI factory" label — not to unleash AI freely, but to place both AI and humans on the same auditable, gated, reversible production line.

References

Project: https://github.com/superplanehq/superplane

Documentation: https://docs.superplane.com/