How can teams deploy seamlessly without complex configurations? How can engineers minimize downtime while automating intricate release workflows? How can developers maintain control over infrastructure without becoming DevOps experts?
Imagine you're on a tight deadline, trying to deploy updates across multiple cloud environments. Each step in the deployment process requires a patchwork of scripts, manual oversight, and constant troubleshooting. One misstep—like an outdated script—can mean hours of backtracking and a frustrated team scrambling to mitigate downtime.
We’ve been heads down on this problem for the last eight months, collaborating with design partners and listening to their real-world pain points. Through research and testing, we’ve zeroed in on the inefficiencies and risks developers face every day in modern deployment workflows.
We believe deployments shouldn’t feel like threading a needle in the dark. Complex configurations and error-prone processes are the status quo—but they don’t have to be. We envision deployment workflows that are intuitive, automated, and resilient. By combining structured code, smart state management, and extensibility, we’re creating a platform that empowers developers to focus on innovation rather than infrastructure hurdles.
The state of deployments
After dozens of interviews with DevOps professionals, here’s what we’ve learned:
- Most teams deploy using CI–and most CI pipelines heavily rely on shell scripts. This is a massive headache for developers. Shell scripts can go wrong for many reasons. When they do, their side-effects can require manual intervention: like retagging a mislabeled Docker image in a registry, editing a Terraform state file, or worse, destroying infrastructure resources in AWS. Shell scripts are brittle and effectful–two traits that make for a one-two punch against human operators.
- Deploys aren’t always push-button. While many teams have moved to automated deployments, that’s not true for everyone. A third of all developers reported deployment complexity as their #1 source of frustration in this year’s StackOverflow developer survey. Sometimes, automated deployments require multiple steps, with human operators punching in familiar CLI commands and tweaking release tags before pushing them to git. For other teams, operators log into a bastion server before they execute their code, limiting the number of machines that have access to production. Not everyone can deploy in a single step.
- Rollbacks are all too common. Operators don’t have many tools to proactively assess release confidence. Most of our tools are reactive. Alerts, metrics, logs, and distributed traces give us insight into what went wrong (and are powerful tools when writing a post-mortem), but they don’t help us prevent outages before they occur. QA only goes so far, and organizations can’t really tell if their code is going to work until it goes live to real end users. Often, there’s not much in between “I tested it on a staging environment” and “It went live to all of our users at once.” Progressive delivery is available to a select few, and most progressive delivery toolkits, like feature flags, won’t catch misconfiguration errors (a super common reason for service disruption) or are oriented toward big enterprise use cases.
- GitOps: some people love it, other people hate it. This ambiguously defined term has been all the rage lately–but is it really that different from continuous deployment? We see the GitOps trend as a veneer over continuous deployment, made distinct only in its tight integration with VCS. It’s not much different than running a CI job on commit.
The MultiTool vision
We envision a world where these problems are a thing of the past. We want:
- Deployments to be robust and idempotent, not brittle and side-effectful.
- Operators should have confidence in their release. They should have the ability to detect outages before they reach their entire user base, limiting both the blast radius of any potential service disruption and the impact to SLOs.
- Continuous release should be available to most SMB SaaS apps. Beyond compliance, the biggest reason most organizations can’t embrace continuous release is that they’re not confident in their release stability. Operators should be able to extend the reach of QA to proactively detect release instability before it becomes a P0.
- Deploys should be push-button. Right now, each app platform has its own deployment method. Serverless functions upload zipfiles or use a CLI; Kubernetes has Helm, Argo, Kustomize, and more; and PaaS like to embrace GitOps or Heroku-style flows. There’s no good reason for this ecosystem fragmentation. All apps go through the same lifecycle: build, deploy, and release. These lifecycle operations should be unified under one tool, no matter the platform.
This is our vision for DevOps. In honesty, if you had asked us ten years ago what DevOps would look like in 2025, we thought all of these issues would be solved by now. We want to meet these expectations and exceed them, to build DevOps software that’s delightful to use and solves technical problems.
Join the waitlist
This is just the beginning. We don’t have all the answers yet, but we’re excited to figure them out with you. Join our waitlist to get early access, and connect with us on GitHub and LinkedIn.
Who we are
MultiTool is built by a team passionate about simplifying developer workflows. Co-founders Robbie McKinstry and Eric Ghildyal bring a decade of experience in cloud infrastructure and platform engineering. Robbie scaled with HashiCorp from 100 to 1000 employees as a research scientist in the office of the CTO, and later worked as a core OSS maintainer at Pulumi. Eric founded and exited a startup (acquired by Elligo Health) in the clinical trials technology space where he was responsible for architecture and DevOps upgrades for all three of Elligo's flagship products. The MultiTool team is committed to delivering solutions that solve real problems and are excited to build the future of deployments together!
