Applications
A purpose-scoped surface per team, with permissions that can be granted for named Applications. Resources can be added by hand or imported from a Docker Compose file; importing grants no execution authority.
Enterprise
One governed estate. Purpose-scoped operations across teams.
resh Enterprise is how teams operate governed execution across an estate: purpose-scoped Applications, managed servers, central administration and visibility — with the authority to change a machine left on that machine.
The operating model
Governing one operation is a design question. Running it across teams is an organizational one.
The platform page explains how a single request is governed. This page is about what an organization needs around that: different teams with different responsibilities over shared infrastructure, one place to administer policy, one place to see what is waiting on a person, and one place to answer what happened.
resh Enterprise provides one governed estate with purpose-oriented Applications for different operational teams. Application permissions determine who may inspect or request operations through that purpose. The runtime on the target server independently applies canonical governance before anything executes.
The resh Enterprise operating model, top to bottom. At the top, Applications are purpose-oriented surfaces for each team — Security Operations, Deployment Operations, Platform Operations — that decide who may see and who may request. A request is relayed down to central management, which administers and aggregates but executes nothing and is not an approval authority: policy administration, Application management, approval visibility, operational views, and evidence aggregation. Below that, managed servers each run a resh runtime that governs every request from scratch and holds the execution authority for its own resources, keeping it if everything above is unavailable: runtime policy, approval, bounded execution, verification, and a local audit trail. At the bottom, the resources — services, containers, configuration, and files on those servers — reached only by a bounded operation.
Applications
Applications organize intent. Runtime governance controls execution.
An Application is a purpose-oriented management surface over resources in the estate — a team’s area of responsibility. An operator scoped to Security Operations sees that Application and its resources, and cannot learn whether another Application exists.
Two checks apply to every request, and neither substitutes for the other. Central management asks whether this person may request through this Application. The runtime asks whether this operation may execute on this resource.
Because membership is organizational, the same service can belong to Security Operations and Deployment Operations at once. That shares visibility of the resource, not authority over it: each request is still checked against its own Application scope and then governed by the runtime, and activity is attributed to the Application it was requested through.
Applications are not tenants, not separate execution authorities, and not policy boundaries. There is one estate, one evidence store, and one runtime policy per managed server. Some read permissions — evidence and approvals, for example — remain estate-wide in this release rather than Application-scoped; that is listed with the current limits.
What resh Enterprise provides
What a team works with, day to day.
Managed servers
Each server runs a resh runtime that joins the estate through explicit enrollment. Enrollment means the server belongs to the estate — it never means the server will do what central management asks.
Central policy, local enforcement
Policy is authored and published centrally, then installed and enforced by each runtime without calling anywhere. An outage of central management removes no controls.
Approvals in one place
A single view of the changes waiting on a person, wherever in the estate they originated. Granting an approval there succeeds only if the runtime’s own policy names that approver.
Operational visibility
Which servers exist, whether they are answering, and what each can govern and verify — read from the runtimes themselves rather than assumed centrally.
Activity & Evidence
Request, decision, approval, execution, and verification records from across the estate, searchable in one place and filterable by Application.
Technical architecture
Central management should not become the biggest executor in the estate.
A single service that can reach every resource is the most valuable target in an environment. So the split is structural: central management — the control plane, in architecture terms — coordinates policy administration, Application management, approval visibility, operational views, and evidence aggregation, while each target runtime retains enforcement and execution authority. Compromising central management could misinform the estate. It could not make a machine act.
It runs no operation
Central management holds no execution engine. It relays a request to the runtime that owns the resource, which governs it from scratch as if it had arrived from anywhere else — and can refuse it.
It cannot grant execution through an Application
Application permissions are management authority: who may see, who may request. Nothing about an Application reaches a runtime’s policy decision, so membership and scope confer no authority to execute.
It cannot approve as itself
Central management shows the approvals that are waiting; it is not the approval authority. An approval is honoured only if the runtime’s own policy names that approver, and the requester can never approve their own change.
It is not the source of record
Evidence is aggregated from the runtimes that produced it, and each runtime’s own audit trail stays authoritative for its facts. The central copy is a searchable view.
The same reasoning applied to approval authority, composition, and evidence is on the security model page.
Product maturity
What this release is, and is not.
resh Enterprise 0.2.0-rc.10 is a pre-GA design-partner preview for controlled, non-production evaluation. Applications, managed-server enrollment, central policy publication, approval visibility, and evidence aggregation are implemented in it.
It is also deliberately narrow. There is no enterprise single sign-on — operators authenticate with issued API keys. Central management runs as one process with one embedded database: no clustering, no failover, and no multi-region deployment. Multi-server rollouts are restricted under the shipped defaults. Nothing is cryptographically signed. Runtimes are supported on current Linux distributions only.
None of that is hidden behind a conversation. The current limits of this release are published so a team can rule resh out before spending a meeting on it.
Enterprise design partners
Would purpose-scoped Applications map to how your teams divide responsibility?
That is one of the questions the design partner program exists to answer. Bring one consequential workflow and the teams who touch it, and we will work through it together in a controlled, non-production evaluation.