SuperPlane: a git-backed control plane for engineering workflows

The gap SuperPlane targets: workflows that outgrow one CI job

Most engineering processes start as a script and end up as a chain of shell commands inside a CI job. That works until the process has to wait for a human, call an incident tool, hold until business hours, or survive a runner restart. SuperPlane is aimed at that point. The README frames it as an automation engine for AI-driven engineering that orchestrates Git, LLMs, CI/CD, observability, incident tools and infrastructure, with durable execution, approvals and an operational UI.

The intended user is a platform or infrastructure team that already owns an internal developer platform and wants the coordination layer to be declarative rather than a pile of glue scripts. The README's example use cases are telling: PR preview environments, policy-gated production deploys, progressive delivery in waves, a release train across several repositories, and first-five-minutes incident triage. Every one of those is a process with more than one system in it and at least one decision point.

SuperPlane does not replace the tools underneath. It calls them. If your deploy is a single `kubectl apply` with no gate, this is a heavier answer than the problem.

Canvases, components and runs: how the engine actually moves

The README describes the model in four layers. A canvas is a graph of steps and their dependencies, and one canvas can express multiple workflows that run concurrently. Each node in that graph is a component, either a trigger or an action, built in or backed by an integration. Triggers match incoming events, and a matched event starts a run with the event payload as input.

The execution layer is where the design gets opinionated. Runs, run items and payloads are tracked across restarts, and the README states that failed steps can resume without custom retry logic. That is the durable execution claim, and it is the main reason to pick this over a script: the state of a half-finished workflow lives in the engine, not in the memory of a process that may be gone.

Memory is app-scoped JSON storage that persists across runs. It is not a database you query; it is a small store the graph reads and writes, and the console dashboards are backed by it along with runs and executions.

Apps are the deployable unit. An app bundles the workflow graph, a custom console UI, app-scoped memory and deterministic execution, and it is versioned in git as `canvas.yaml` and `console.yaml`. That file layout is the clearest signal of intent: the workflow definition is reviewable in a pull request the same way application code is. Whether the console definition belongs in the same review as the graph is a judgement call the README does not address.

Installing SuperPlane locally and getting to a first run

The quickest path in the README is the demo container. It pulls a stable image and runs it on port 3000 with a named volume for the data directory.

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

After the container starts, the README says to open http://localhost:3000. That instance is the demo image, not the full self-hosted engine; the README points to the installation guide at docs.superplane.com/installation/overview/ for self-hosting the core engine, and to app.superplane.com for the managed cloud with runners and one-click app installs.

For a guided first workflow, the README links a quick start guide at docs.superplane.com/get-started/quickstart/. The repository also carries `docker-compose.dev.yml` and a `.env.example` for local development. That file is explicit that it is read by Docker Compose for variable interpolation and is not a generic env_file, so a variable only reaches the app container when the compose file references it. It also warns that if you change `PUBLIC_API_PORT` you should keep `BASE_URL`, `WEBHOOKS_BASE_URL` and `ALLOWED_WS_ORIGINS` aligned. Ports and variable names come from that file; do not invent others.

If you would rather run the engine from source, the repository has a Makefile with a `dev.up` target and a Dockerfile that installs Go 1.26.2, Node.js, the PostgreSQL client, gomigrate and protoc into a development stage. The README does not present that as the supported install path, so treat it as the contributor route.

Where SuperPlane is the wrong tool, and where the beta bites

The README is direct that SuperPlane is in beta and that core primitives and integrations are maturing, with breaking changes possible. That single sentence should shape an adoption plan. A control plane sits in the path of deploys and incident response, so a breaking change in a canvas schema or a component's inputs is not a cosmetic upgrade.

The second constraint is scope. SuperPlane coordinates tools; it does not build, test or host your artifacts. If your problem is that a build takes forty minutes, this project has nothing to say about it. If your problem is that a build takes forty minutes and then three teams argue about who approves the release, it does.

The third is the integration surface. The README lists a wide set of providers across AI and LLM, version control and CI/CD, and cloud and infrastructure, and points to a components page for the full list. The list is truncated in the README itself, so the honest move is to check the documentation for the exact provider and event you need before designing around it. A workflow that depends on an event type the integration does not emit will not be saved by the engine.

Finally, self-hosting the core engine means you own a Postgres instance, an OTLP endpoint if you want traces, and the upgrade cadence. The repository ships an `otel-collector-config.dev.yaml` and the Go module pulls in OpenTelemetry exporters, so tracing is part of the expected deployment shape rather than an afterthought.

SuperPlane against a general-purpose workflow engine

The obvious comparison is a general workflow orchestrator such as Temporal or Airflow. The difference is not the durability model, which all three take seriously, but what the unit of work is. In those systems the unit is a task in a program you write and deploy as code. In SuperPlane the unit is an app whose graph lives in `canvas.yaml` and whose UI lives in `console.yaml`, both in git, with an operator-facing console generated from the same definition.

That pushes SuperPlane toward the platform-team use case and away from the data-pipeline use case. A data engineer who wants backfills and a scheduler will find more in Airflow. A platform engineer who wants a deploy gate that an on-call engineer can see and approve in a console, with the approval recorded against a run, is closer to what SuperPlane describes.

A second, less obvious alternative is doing nothing new and extending your CI provider's pipeline features. That is genuinely cheaper for a single linear pipeline. It stops being cheaper the moment the process has to wait days for an approval, fan in from several repositories, or write state that a later run reads. Those are the shapes SuperPlane was built for.

Licence, upgrade cost and the maintenance picture

SuperPlane is licensed under Apache-2.0, with a LICENSE and a NOTICE file at the repository root. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices; it does not impose copyleft on your own workflow definitions. That is a reasonable fit for a control plane that a company will embed in its internal platform. This is a description of the licence text, not legal advice, and anyone redistributing a modified engine should read the NOTICE requirements themselves.

The repository is not archived. The last push was on 2026-07-27, which is more than six months before today, so there is no basis for calling it actively developed. The release history shows v0.28.0 on 2026-07-09, v0.29.0 on 2026-07-16 and v0.30.0 on 2026-07-27, a cadence of roughly weekly minor releases in that window. Anyone planning an upgrade should read the release notes for those versions rather than assume the pace continues.

Upgrade cost has two parts. The engine itself is a container image and a database, and the repository carries migration tooling in `db/` plus a `gomigrate` install in the Dockerfile, so schema migrations are part of the deployment. The second part is your own canvases. Because they are versioned files, a schema change shows up as a diff you have to resolve. The README does not document rollback for an app definition, so plan the upgrade path before you need it.

Editorial conclusion

Adopt SuperPlane if your workflows span several systems, need approvals or must survive a process restart, and you can absorb beta churn: the README states breaking changes are possible. Do not adopt it as a general CI replacement or for a single linear pipeline that your existing CI already runs well. Before committing, verify the install path at docs.superplane.com/installation/overview/, confirm which integrations your stack needs against the components list, and read canvas.yaml and console.yaml in a real app to see how much of your process ends up as files in git.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes