A guided technical evaluation
Direct access to the people building resh, without a sales layer in between.
Design partner program
Bring us one consequential operational workflow.
Work with us to find out whether a real operational change can be governed from request through verified outcome. This is a free, guided evaluation of a pre-GA design-partner preview — not a GA product, not a purchase, and not a sales process.
What we evaluate
One workflow, taken all the way through.
Take a simple example: an operator or an automation asks to restart an API service. The evaluation is whether resh can resolve the resource, evaluate governance, hold the request for approval if necessary, execute the bounded restart, independently verify the service state, and record the evidence — for a workflow that matters to you.
The question we are testing
Once an agent or an automation has already been authenticated and authorized, does your team still need a separate layer that governs the resource change itself and checks the resulting state?
You do not need to replace anything to find out. An evaluation changes nothing about the identity, gateway, or automation tooling you already run, and “what we have is enough” is an answer we want to hear with the reasons attached.
A design-partner evaluation scenario in seven steps. One: a request to restart an API service. Two: resh resolves the resource. Three: governance is evaluated, and may refuse. Four: approval, if necessary. Five: the bounded restart is executed. Six: the service state is independently verified. Seven: the evidence is recorded.
What you receive
A structured evaluation, not a demo.
A bounded, non-production deployment
The preview installed on Linux hosts you control, in a lab or sandbox — not in production.
Workflow mapping
Your chosen workflow expressed as modelled resources and operations, including the parts that do not map.
Governance and approval modelling
Which operations policy should allow, refuse, or hold for an approver — and who may approve.
Execution and verification assessment
What resh can execute and independently verify for your workflow today, and what it reports as unsupported.
Evidence review and influence
A walk through the resulting Activity & Evidence, and direct input into what a pilot would need next.
What we would ask of you
- One real workflow — an operation where automation or an agent changes something consequential.
- A controlled, non-production environment to evaluate in, and a technical owner with a few hours.
- Candid technical feedback. Disagreement is more useful to us than validation.
Who it suits
- Teams that operate Linux infrastructure and have consequential operational workflows.
- Teams using, or evaluating, AI or automation for operational changes — including those that already authorize what an agent may call and still cannot say what it changed.
- Teams that care about who may authorize, who may approve, and what can be shown afterwards.
What we are not promising
- A production-ready platform. This is a pre-GA preview and we will not pretend otherwise.
- Custom engineering for every request, or a delivery date we cannot yet stand behind.
- That governed execution is the right answer for you. Finding out early that it is not is a good outcome.
Who usually leads one
- Head of Platform Engineering
- Director of Infrastructure
- SRE leader
- DevOps leader
- Security Engineering leader
- AI platform or agent infrastructure leader
Not sure whether your team is a fit? See who resh is being built for, and who it is not for yet.
Before you evaluate
What this release does not do.
resh is a pre-GA design-partner preview for controlled evaluation. This list is published here rather than kept for a later call: learning a limitation late costs more credibility than it saves meetings, and a team that rules resh out on one of these has been served well by this page.
Current evaluation scope
What an evaluation is, and what it runs on.
Maturity
resh 0.2.0-rc.10 is a pre-GA design-partner preview, and a release candidate at that. Every provider reports its own stability as experimental. There is no service-level commitment and no production deployment.
Platform
Linux x86-64 only, and the binaries require glibc 2.39 or newer. Ubuntu 24.04+, Debian 13+, and Fedora 40+ are fine; several older enterprise distributions are not. No Windows runtime.
Operations
resh governs modelled resource operations — services, containers, configuration, files — not arbitrary shell commands. A system with no provider is outside the boundary. Verification applies where an operation declares how it can be observed; otherwise it is reported as unsupported.
Approval
Nobody can approve until runtime policy names them as an approver. Approving a held operation also executes it; there is no approve-now, run-later state.
Current platform limits
Where the design stops in this release.
Applications
Applications are purpose-scoped management surfaces, not tenants. Some read permissions — evidence and approvals among them — remain estate-wide rather than Application-scoped, so scope operators by environment as well as by Application.
Deployment
Central management is one process with one embedded database: no high availability, no clustering, and no multi-region deployment. Multi-server rollouts are refused under the shipped defaults.
Integrity
Nothing is cryptographically signed, and there is no write-once evidence storage. Checksums detect corruption; they do not establish authenticity against a compromised distribution channel.
Recovery
No rollback, no retry, and no continue-on-error — deliberately. resh claims no undo it cannot perform; a change that fails or does not verify is reported and stops.
Not yet included
Things an enterprise evaluation usually asks about first.
Identity
No enterprise SSO. There is no OIDC, SAML, SCIM, directory integration, or MFA enforcement — operators authenticate with issued API keys.
Integrations
None with external secret managers, ticketing, CI/CD, or chat systems, and central management does not export metrics.
None of this changes what the model is for. It changes whether this release is useful to you this quarter, which is a question worth settling first. The security model page covers the same ground from a control perspective.
Apply
Apply to become a design partner.
There is no cost, no licence to sign, and no procurement step, and either side can end the evaluation at any point. Applying is one email. The button below opens a message in your own mail client with these prompts already in it — answer what you can and delete the rest.
- Name
- So we know who we are talking to.
- Work email
- Your mail client supplies this.
- Company and role
- Which team owns the workflow.
- The operational workflow you want to govern
- One is enough. A sentence or two.
- Current automation or AI usage
- What changes infrastructure today, and with what access.
- Controls already in front of it
- Identity, a gateway, approvals, or nothing yet. Kinds of control only.
- Systems involved
- Kinds of system only — for example Linux services or containers.
- Evaluation environment
- Whether a non-production Linux environment is available.
- Primary concern
- Execution authority, approvals, verification, evidence, AI agent access, or something else.
Please do not send secrets. No passwords, credentials, production configuration, or sensitive production details. A general description of the workflow is all we need to start.
Email your design partner applicationIf the button does nothing, your browser has no mail client configured — write to partners@reshhq.com directly. Nothing is submitted to this website and nothing is stored by it. If you would rather ask questions before describing anything internal, say so and we will start there.