Platform engineering
Owners of the operational surface
Teams standardizing how consequential resource operations are exposed to the rest of the organization, including to automation.
Who it is for
Who resh is being built for.
resh is a pre-GA design-partner preview and has no customers to point to yet. This page describes the teams governed execution is being designed around, and how to get involved while it is being built.
Intended audience
Teams giving automation real operational authority.
DevOps
Owners of change execution
Teams whose scripts and automation hold the broadest credentials, because scoping each step was harder than granting everything once.
SRE
Owners of production outcomes
Teams that carry the consequences when an automated action half-succeeds and nothing detects it.
Infrastructure operations
Owners of the hosts
Systems administrators who want routine operations on Linux servers to stop requiring standing shell access.
Security engineering & operations
Owners of the trust boundary
Teams deciding what authority automation and agents should hold, and needing bounded operations of their own over shared infrastructure.
Engineering leadership
Owners of the decision
Leaders evaluating agentic operations who need a defensible answer to how much an agent is allowed to change.
Qualification
Is resh a fit for you right now?
Both halves are published, because finding out in two minutes that this is not for you is a better outcome for both of us than finding out in the second meeting.
A strong fit if
- An AI agent, an internal automation platform, or a self-service tool either has infrastructure execution rights or is being blocked from getting them.
- You operate Linux infrastructure, and more than one team needs to act on the same systems.
- The block is about consequence rather than authentication — somebody can authenticate the caller and still cannot say what it would do.
- A team owns change execution, not only change approval: platform engineering, SRE, infrastructure, or an internal developer platform.
- A bad change has a real cost, whether the estate is thousands of hosts or a small number of high-consequence ones.
- Audit, internal risk, or customer commitments make “prove what happened and why it was allowed” a recurring expense.
- Somebody has already tried to answer “how would we let an agent do this safely?” internally and did not like their own answer.
Probably not yet if
- Nothing other than a person can currently change production, and nothing is scheduled to. resh solves a problem you do not have yet.
- The requirement is enterprise SSO, a signed supply chain, or a compliance attestation on day one — none of which this release provides.
- The estate is not Linux, or cannot run a host on a current distribution.
- What is wanted is an agent framework, a workflow engine, or a configuration management tool. resh sits underneath those and replaces none of them.
- A production-ready platform is needed now. resh is a pre-GA design-partner preview, and evaluations run in a controlled, non-production environment.
- The goal is general business-process automation. The current product is built for infrastructure operations.
Where resh is today.
resh is being developed, not deployed at scale. There are no customer references, case studies, testimonials, or production deployments to cite, and this page will not imply otherwise until there are.
What exists today is a working design-partner preview, an open-source foundation, and a design partner program for teams working on the problem now. If you are exploring AI-assisted infrastructure operations or governed automation, the most useful thing you can bring is how you are solving it today.
Before there are customers, there are collaborators
Being early is the point.
Working with resh now means the model gets shaped around problems you actually have, rather than arriving as someone else’s assumptions three years from now. We are looking for a small number of teams who care enough about this problem to argue with us about it.