RenvorRenvor
In development / prerelease

Visible routes. Explicit ownership. Renvor is shaping application infrastructure for Rust teams around a tested transport-independent kernel.

The kernel, CLI, HTTP transport, validation, persistence adapters, and authentication paths run in workspace tests. No crate is published; the facade does not expose persistence or authentication, and generated clients do not exist.

Read the sourceTrace the design
kernel lifecycleroutes ready
  1. 01Load
  2. 02Validate
  3. 03Register
  4. 04Boot
  5. 05Ready
  6. 06Drain
  7. 07Stop
Load, Validate, Register, Boot, Ready, Drain, Stop
Two routes through visible framework gatesThe REST and HTTP route passes through validation, and the CLI and generator route passes through configuration. Both enter an ordinary Rust application core.

Visible routes / explicit ownership

The framework boundary should stay readable when the system gets real.

Renvor is being designed around one strong idea: framework choices belong at visible boundaries, while application services stay ordinary Rust. The kernel, CLI, generator, REST and HTTP adapter, validation boundary, and API description now prove that shape in workspace tests. The broader application stack is still being built.

  1. Framework inputsCLI + HTTP
  2. Visible gatesvalidation + configuration
  3. Application coreordinary Rust

Phases 002 to 009 / implemented and tested

A tested route through the junction.

Seven ordered lifecycle phases, provider dependencies, layered configuration, bounded deadlines, cancellation, rollback, REST and HTTP delivery, runtime validation, Problem Details, OpenAPI 3.2, persistence, and authentication are implemented and tested.

Configuration route

Every value keeps its source.

Layered configuration retains per-key attribution while secrets stay redacted from every diagnostic path.

  1. 01defaultsbase
  2. 02filelayer
  3. 03environmentoverride
  4. 04CLIexplicit
Release route

Implemented does not mean published.

No crate or executable is published. Generated projects cannot resolve Renvor, and the implemented database and authentication crates are not reachable through the facade.

  • workspacetested
  • registryunpublished
  • installunavailable
Delivered in Phase 004 / unpublished

A visible route into the service.

The opt-in REST and HTTP delivery adapter is implemented and tested against real routers. It owns declarative routes, middleware order, trusted-proxy identity, host validation, CORS, limits, and graceful drain. GraphQL is planned for 2.0 and does not exist.

  • Real-router test evidence
  • OpenAPI 3.2 description
  • Fail-closed request boundaries
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

Phase 003 / implemented and tested / unpublished

Transactional project generation

The CLI and generator run from source, preserve safe writes, and record project choices.

renvor newNo supported install command exists. The CLI is implemented and tested, but no package is published.
Planned for Renvor 4.0

Installable capability packages

Packages are designed to join existing projects through a versioned contract.

renvor add renvor-rbacUnavailable. No package has been published.

One request. Four visible stages.

A request enters through one visible route, crosses policy and transaction boundaries at an owned junction, reaches replaceable capability ports, and returns through one typed error contract.

Request and typed return routeAn HTTP and REST request enters the system, crosses an owned policy and transaction junction, reaches a replaceable capability port, and returns through an RFC 9457 Problem Details contract.
  1. 01 / Entry

    HTTP / REST

    A request enters through one visible transport route.

  2. 02 / Owned junction

    Policy + transaction

    Policy and transaction boundaries meet at one owned junction.

  3. 03 / Capability port

    Provider boundary

    The route reaches a replaceable capability through its provider boundary.

  4. 04 / Typed return

    RFC 9457

    Failures return through one typed Problem Details contract.

One route / end to end

Trace the intended system without mistaking plans for product.

Three panels describe implemented work today: the CLI, core, and selected capability ports. Every panel states its evidence and limits plainly.Scroll to trace the system

Interactive CLI

Delivered in Phase 003 · unpublishedimplemented and tested

Ask the decisions that shape the project.

The `renvor` command and its transactional project generator are implemented and tested. The wizard records transport choices, supports flags and machine-readable output, and refuses unsafe writes. Nothing is published, so generated projects cannot yet resolve a Renvor dependency.
Project setupWhich database?
PostgreSQL / selected
MySQL
4 of 9 decisionsIllustrative state. The CLI exists only in source today.

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 stays transport-independent by requirement. The CLI and opt-in REST and HTTP adapter call it through visible boundaries; GraphQL does not exist.

Capability ports

Delivered in Phases 006–009 · unpublishedpartly implemented and tested

Use mature crates without binding the whole app to them.

Narrow boundaries isolate capabilities so implementations can evolve independently. Persistence ports have SQLx and SeaORM adapters tested on PostgreSQL and MySQL, and authentication defines mail and audit ports with deterministic recording sinks. Production mail, queue, storage, and cache adapters do not exist, and persistence and authentication are not exposed through the facade.
SQLxSeaORMMailJobsStorageCache

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 client generator or published API endpoint exists.
Next.js
Leptos
Tauri

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.

Reviewed language / verified evidence

A lifecycle with a way in, a way through, and a deliberate way out.

The sequence below is the current kernel, not a future promise. Assembly is synchronous. Boot is asynchronous. Failed boot rolls back what it started.

Kernel interlocking / ordered lifecycleSeven phases. One controlled route.
01 / Load
  1. 01Load
  2. 02Validate
  3. 03Register
  4. 04Boot
  5. 05Ready
  6. 06Drain
  7. 07Stop
Phase 002 / implemented and tested

Lifecycle and provider graph

The kernel owns ordered phases, dependency resolution, bounded work, rollback, liveness, and readiness.

Phases 004 and 005 / implemented and tested

REST, validation, and API description

The opt-in REST and HTTP adapter, runtime validation, RFC 9457 failures, OpenAPI 3.2 generation, and compatibility gate run in workspace tests.

Phases 006–009 delivered / unpublished

Persistence, identity, clients, and packages

SQLx and SeaORM adapters, four-row database evidence, authentication, sessions, and optional tokens exist. Client generation, desktop packaging, and installable packages do not.

evaluation lens

Routes stay visible

Handlers, services, policies, ports, configuration, and errors stay ordinary Rust types with searchable ownership. The tested kernel, transactional generator, and opt-in REST adapter use this shape today. Frontend and package generation do not exist.
Lens 1 of 3

In development / prerelease

Follow the route. Inspect the junction.

There is nothing to install. The source, governance, plan, tested kernel, CLI, HTTP adapter, validation, persistence, authentication, and OpenAPI evidence are public and readable today.

Browse the sourceRead the documentation