Access to tools
It’s become a common saying— but mostly because it’s true: software runs your business, and software engineers make it all possible.
Engineers do their work with tools: editors, terminals, web browsers, documentation, and much more. Tools enable their work.
A lot of attention goes to tools that help you write software. But tools for the people actually operating software have lagged behind: the tools you use when you debug a Kubernetes cluster, when you do time-critical incident response; or just when you do ordinary day-to-day remote ops work.
We want to give engineers the best, safest tools to do their best work—in production environments— because critical work in production is the highest-risk, yet often the most important work, they do.
Tooling matters. A recent case study from McKinsey shows a real correlation between developer velocity and key business performance indicators. The data also shows that the key contributors to developer velocity are developer tools, DevOps tools, and collaboration tools.
Most people are still doing work in their local terminal with ad-hoc SSH to resolve customer and production issues. There's no uniformity, no logging, no approvals, no visibility—it's as if everything we've learned about best practices for development get thrown out the window when it comes to production work.
Many organizations need a better way to work in production but don’t have the time and resources to architect a secure and compliant solution.
Existing third-party solutions don’t solve the problem either. There are too many security and compliance issues involved when using multiple software vendors that have production access. It’s also hard to manage standardization across different teams when everyone is using different tools.
So that’s why we founded Cased. We want to make all of this better.
Our vision for Cased is simple: bring brilliant developer experience to people working in production, tailored for the cloud-native world.
We're tackling this problem in three ways: with automated runbooks, a web shell built for both Kubernetes and traditional SSH, and approval workflows.
Cased's runbooks automate the complex tasks that your engineering and support teams do everyday. With standardized, codified processes, they help reduce operator error, the biggest cause of production outages. With logging and approvals, they are secure and compliant. Engineers can run commands in production with just the right amount of production access.
But sometimes you just need a shell in production to get work done. Cased brings everything we love about the modern web—collaboration, simple and secure authentication, fast and delightful UX, and more—to the old reliable terminal interface that every developer knows.
Cased's shell is a web application, running on your own infrastructure, that combines the power of a remote terminal with the ease of your existing IdP access control. It makes use of one-time use SSH certificates, the best practice for SSH access—meaning no more SSH keys to manage.
And it does a lot more than that: Cased improves developer experience with session recording, session sharing, complete audit logging, and an API to extend functionality. Cased can even auto-discover the location of your remote hosts, so no more need to manage inventory lists. Access the prompt you need in just one-click. In-terminal shared snippets help build a standardized technical foundation with easily searchable and reusable one-liners.
Cased also brings approval workflows for SSH access and shell programs to help with visibility and operational controls. Production access doesn’t have to be something organizations are afraid of giving their engineers due to no visibility of what happens in the shell. It doesn’t have to be scary—giving access is secure and safe with Cased. By reviewing production shell commands, SQL queries, or scripts before they're run, you won’t have to worry about missing your customer SLAs or any unplanned downtime. Everything is logged and audited to know what people are doing.