SuperPlane Is Open Source

This week we open-sourced SuperPlane, a DevOps control plane for running event-driven workflows across the tools you already use. You can think of it as ‘n8n/Zapier for DevOps’ that sits on top of Git, CI/CD, observability, infrastructure, and the rest of your production system.

Why does this matter? To evolve, DevOps needs to move on from one-off scripts, tribal knowledge, and untraceable workflows.

For years, the best automation tool at hand was the humble CI job. Pipelines are great at building and testing code, but they are not great at running workflows that span multiple tools and repositories, pause for human intervention, and run for hours or days.

What we need is a vendor-neutral interoperability layer for DevOps automation; a way for tools, humans, and agents to talk to each other, with domain-specific channels and components. This launch is the alpha release of that layer, starting with 40+ core components and integrations.

A few links if you want to kick the tires:

Ultimately, the goal is to make it safe to describe what you want in natural language and have the system execute it in a safe, auditable way. It’s a journey, and we’re committed to keeping it open and transparent.

You Need To Change The Whole Assembly Line

In the DevOps Paradox episode 2026 — The Year of Discovery, Viktor and Darin talk about how software work is changing, but the bottlenecks aren’t where people think.

A few quotes are basically a version of why we started SuperPlane. My comments below.

You cannot just give developers, here’s AI. Everything else stays the same… you need to change the whole assembly line.

Most organizations are currently applying AI to optimize the coding process. The constraint will simply move downstream: releases, verification, coordination, incident handling. If you don’t address the system, you get faster queues, not faster outcomes.

You have a platform that you can say, hey, give me a database, and you get that database. And that database is done based on your company’s best practices, rules, policies […] ask me questions that I need to answer and don’t ask anything more.

This is what engineers are actually asking for: outcomes, and systems that hide incidental complexity without hiding state.

People simply don’t want to… relinquish part of their power… [and] don’t want to introduce randomness in production.

This is the hard part. It’s not so much a capability problem as much it’s a trust problem. People will only use automation in production when it’s controllable, auditable, and fails in predictable ways.

To get there, I think we need a control plane that makes cross-tool operational workflows explicit and inspectable: what triggered, what ran, what it touched, and what evidence it produced. If you can’t explain a change, you can’t safely automate it.