About

ControlPlane Labs (CPLabs) builds infrastructure tooling for teams that manage email authentication, DNS, certificates, infrastructure execution, compliance, software supply chain, and command execution. Shaped by a decade in DevOps and infrastructure; focused on making correctness provable and security the default.

What we work on#

Infrastructure teams manage systems that send email, serve DNS, present certificates, execute changes, manage permissions, and deliver software. These systems share a structural problem: they are managed by separate teams, with separate tools, separate credentials, and separate audit trails. When something breaks, correlating across systems is manual. When an auditor asks “prove this change was safe,” nobody has a single answer.

We are building tooling that treats these as one problem.

Email authentication. SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT: six protocols designed independently, deployed independently, broken independently. Most organizations have email authentication that technically exists but functionally does not protect the domain. The SPF 10-lookup limit is an engineering constraint that most teams discover only when legitimate mail starts failing.

DNS management. DNS is the last imperative infrastructure. Every other piece of infrastructure has a declarative workflow; DNS has a web console and a prayer. Provider APIs are wildly inconsistent, drift is invisible, and switching providers is one of the most anxiety-inducing operations in infrastructure.

Certificate visibility. Certificate management tooling tells you what certificates exist. It does not tell you what certificates are actually being served at each endpoint. The gap between the certificate you renewed and the certificate a client receives in the TLS handshake is where outages happen.

Infrastructure execution. CI/CD pipelines have production credentials that exist 24/7 whether a pipeline is running or not. Approval workflows are behavioral, not architectural. The question most teams cannot answer: can you prove that every infrastructure change was approved before it ran?

Compliance and audit. When an auditor asks for evidence, most teams start an archaeological expedition across CloudTrail, GitHub, Slack, and Jira. Compliance evidence should be a query, not a project.

Software supply chain. Your Tuesday build and your Wednesday build installed different packages because upstream repositories are mutable infrastructure. Version pinning constrains the version string; it does not constrain the repository state.

Command execution. Anyone executing infrastructure changes (humans, scripts, CI pipelines, AI agents) faces the same credential problem: the operator needs credentials in their environment to do the work. Process isolation protects the host; it does not protect the credentials. These are different problems, and credential isolation is the missing piece.

What we believe#

• Infrastructure should be portable and provider-flexible.
• Security works when it is architectural, not aspirational. Prevention over detection.
• Every production change should be provable: who changed it, when, was it approved, what happened.
• Credentials should not exist outside the context of an approved change.
• No vendor lock-in. Your infrastructure, your providers, your choice to leave.
• Take your data with you. Host it yourself.

Open source#

We publish reusable tooling and components as we build. See /open-source/ for how we approach OSS and where to find our work.