RenvorRenvor

running register / application infrastructure / rust

The plan: generate the backend, typed client, authentication, desktop shell, operating contracts, and package boundaries as one inspectable application. Phase 002 has delivered the core those pieces attach to — a tested, transport-independent kernel. Everything else on this page is still a design.

Read the source →Tour the design ↗
lifecycle register— · standby
  1. 01Load
  2. 02Validate
  3. 03Register
  4. 04Boot
  5. 05Ready
  6. 06Drain
  7. 07Stop
01Load
02Validate
03Register
04Boot
05Ready
06Drain
07Stop

Every application surface is designed to connect to one stable core.

Renvor aims to provide a coherent default path while preserving the boundaries that experienced Rust teams need to inspect and change. Each surface below carries the release that owns it, and none of the four has been delivered. The core they are designed to connect to is the part that exists.

Planned for Renvor 1.0

Typed services with visible work.

The design: REST — and opt-in GraphQL in 2.0 — will enter through transport adapters, then reuse the same application services, policies, transactions, and error vocabulary. No transport adapter exists. The kernel those adapters are meant to call does.

  • OpenAPI 3.2 contract
  • Shared service layer
  • Explicit async and transactions
application::contract
pub trait Capability {
  type Config;
  type Error;

  async fn start(
    &self, ctx: Context
  ) -> Result<Handle, Self::Error>;
}

illustrative shape — not a published API

Planned for Renvor 1.0

Interactive generation

Questions are designed to adapt to previous answers, stopping invalid combinations before generation.

renvor newNot installable — the CLI is unbuilt and unpublished
Planned for Renvor 4.0

Installable packages

The design adds RBAC and later capabilities to existing projects through a versioned package contract.

renvor add renvor-rbacNot installable — no package has been published
recorded intent

The intended shape: a request enters through a transport, crosses policy and transaction boundaries in the application service, reaches replaceable capability ports, and returns through one typed error contract.

register 02 / the design, end to end

From first answer to installed capability.

One of the five panels describes something that exists today — the core. Each panel states which it is.Scroll to trace the system →
impression 01 / 05

Interactive CLI

Planned for 1.0not built

Ask the decisions that shape the project.

The wizard is designed to adapt its questions to the selected transport, database, ORM, authentication, frontend, styling, desktop, and deployment target. It is not implemented, and no executable exists.
Project setupWhich database?
PostgreSQL ✓
MySQL
4 of 9 decisionsDesign mock-up — this wizard does not exist
impression 02 / 05

Stable core

Delivered in Phase 002 · API unstableimplemented and tested

Keep transports outside the application service.

The kernel owns the lifecycle, provider registration and dependency resolution, layered configuration, cancellation, bounded deadlines, and independent liveness and readiness. It is transport-independent by requirement: there is no HTTP server and no way to receive a request. REST, CLI, and later GraphQL are meant to call it through visible typed interfaces — none of them exists yet.
impression 03 / 05

Capability ports

Planned for 1.0port shape only

Use mature crates without binding the whole app to them.

Narrow boundaries are designed to isolate persistence, mail, queues, storage, cache, and observability so implementations can evolve independently. The kernel defines the provider and configuration ports; no persistence, mail, queue, storage, or cache implementation exists.
SQLxSeaORMMailJobsStorageCache
impression 04 / 05

Full-stack contract

Planned for 3.0not built

Generate clients from one versioned API shape.

Backend contracts, frontend types, auth state, error handling, and regeneration rules are designed to stay synchronised across Rust and Next.js clients. No generator exists, and there is no API to generate from.
Next.js
Leptos
Tauri
impression 05 / 05

Package ecosystem

Planned for 4.0not built

Add new capabilities to applications already running.

Independent crates are designed to use a package SDK for registration, configuration, migrations, source generation, diagnostics, and safe removal. No SDK and no package exist.
renvor add renvor-rbac

✓ package registered

✓ migrations discovered

✓ policy tests passed

Design mock-up — this command does not exist

One backend contract. The frontend your team prefers.

The design: generated clients sharing versioned types, authentication state, error behaviour, and contract regeneration, with styling a project choice rather than a framework requirement. No client generator exists, and none of the five targets below is supported today.

target 01

Next.js

SSR or CSR for web. Static CSR for Tauri.

CSS · SCSS · Tailwind
target 02

Yew

Component-based Rust UI with typed clients.

CSS · SCSS · Tailwind
target 03

Dioxus

Hooks-based Rust UI across supported targets.

CSS · SCSS · Tailwind
target 04

Leptos

Fine-grained reactive Rust applications.

CSS · SCSS · Tailwind
target 05

Tauri

Desktop packaging for supported static clients.

CSS · SCSS · Tailwind
Backend planned for 1.0 · screens for 3.0

Authentication is designed to reach across the stack.

Backend routes, credential handling, verification, recovery, rate limits, and audit events are planned for 1.0; frontend screens, typed state, and end-to-end tests for 3.0. Nothing generates authentication today.

RegisterVerifySessionPolicy

Production behaviour is designed in, not added later.

Lifecycle, diagnostics, observability, supply-chain policy, release evidence, and recovery are specified before the first production deployment. The lifecycle below is implemented and tested; the transports and adapters that would drive it in production are not. The governance, verification sequence, and release policy are real and public.

01Load
02Validate
03Register
04Boot
05Ready
06Drain
07Stop

Load → Validate → Register → Boot → Ready → Drain → Stop. Seven phases, in that order, implemented in the Phase 002 kernel. Assembly is synchronous; boot is asynchronous and rolls back what it started if a provider refuses to come up.

impression a

Security gates

Secret scanning, dependency and licence policy, redaction, bounded work, safe defaults, and release attestations. Secret scanning, licence policy, and release attestation run today on the framework repository. Secret redaction and bounded work are implemented in the kernel. Deployment-time controls are planned.

impression b

Diagnostics

Actionable startup failures, configuration validation, generated-project checks, and package health diagnostics. Startup failures and configuration validation are implemented and tested in the kernel. Project and package diagnostics need a generator and a package system, and are planned for 1.0 and 4.0.

impression c

Observability

Structured logs, traces, metrics, health, readiness, graceful drain, shutdown, rollback, and recovery. Phase spans, independent liveness and readiness, the drain gate, and rollback on failed boot are implemented. Metrics export and deployment recovery are planned for 1.0.

The Ordered Register identity world: seven equal-width marine billets of rising, held, and falling heights above the words Load, Validate, Register, Boot, Ready, Drain, StopThe Ordered Register identity world: seven equal-width ice billets of rising, held, and falling heights above the words Load, Validate, Register, Boot, Ready, Drain, Stop
Ordered Register — every stage leaves a readable proof.

evaluation lens

Strong types stay visible

Handlers, services, policies, ports, configuration, and errors are meant to stay ordinary Rust types with searchable ownership. The Phase 002 kernel already works this way. The generators that would produce the rest of an application do not exist.
Lens 1 of 3

A package ecosystem designed for applications already in motion.

None of these packages exists. The names below are reserved by design, not published — neither renvor nor renvor-cli is on crates.io.

crate 01renvor-authnot published
crate 02renvor-rbacnot published
crate 03renvor-storagenot published
crate 04renvor-mailnot published
crate 05renvor-jobsnot published
crate 06renvor-cachenot published
crate 07renvor-observenot published
crate 08renvor-testingnot published

In development — no release

Follow the work. There is nothing to install yet.

No crate is published and the documentation site is not deployed. What is public and readable today is the source, the governance, the verification sequence, the plan — and a tested transport-independent kernel you can read, build, and run the test suite against.

Browse the source ↗Read the plan ↗