Handler-first.
Runtime-aware.
Application-ready.
Build typed Rust APIs, background work, cron, channels, commands, services, OpenAPI, and console visibility from one coherent application model.
Handler-first.
Vyuh proof points
-
Rust-native
Typed async handlers with explicit data and error boundaries.
-
Handler-first
Typed inputs, validation, and responses stay together.
-
Runtime paths
Routes, tasks, cron, channels, commands, and services share a model.
-
OpenAPI
Schemas and docs come from registered handlers.
-
Console
Operations, config, runtime health, and tasks are inspectable.
-
Bundles
Application features compose without scattered registries.
If Vyuh can run it, Vyuh can describe it.
Routes, tasks, signals, emitters, services, schemas, OpenAPI, runtime config, and system health are registered into one inspectable surface.
See the whole application shape without stitching together separate dashboards for routes, workers, docs, and services.
One handler model. Many runtime paths.
Vyuh treats application behavior as typed handlers, not scattered subsystems. The same signatures, data model, errors, auth, validation, and observability apply across them.
Durable background work, without a second application.
Run emails, imports, reports, retries, approvals, and polling as typed handlers registered beside your APIs.
Tasks can sleep, suspend, resume, retry, fail, and store typed results while staying visible in the console.
Typed input
Submit Data<T> by task type and reuse route-style data.
Continuation state
Sleep or suspend work without keeping a Rust future alive.
Explicit retry
Return retry state when work should run again later.
Console visible
Inspect state, payloads, retries, results, and failures.
Schedules and triggers become typed runtime inputs.
Run cron, intervals, polling, retries, and external notifications as registered typed emitters.
Emitters keep trigger logic close to the bundle and hand off to tasks, signals, or channels.
Cron and intervals
Register recurring work as named runtime behavior.
Typed emissions
Produce typed data for tasks, signals, channels, or services.
Bundle-owned
Keep schedules beside the feature that owns them.
Console visible
Inspect registered emitters from the same console.
Live application streams, without a second realtime stack.
Publish typed events to browsers, services, and subscribers through channels beside routes and tasks.
Channels make pub/sub and SSE-style delivery part of the explicit application model.
Typed messages
Keep live payloads in the same typed data model.
Subscriber routes
Expose streams through the same routing surface.
Fan-out targets
Connect signals, tasks, emitters, and external clients.
Runtime visibility
Keep channels discoverable beside every runtime path.
Docs generated from the runtime model.
Generate OpenAPI from handlers, schemas, auth, permissions, and middleware registered in the app.
Override generated docs through macros or direct APIs when contracts need extra precision.
Automatic by default
Routes, inputs, outputs, and schemas feed the document.
Override when needed
Use macros or direct APIs for exact operations.
Security included
Model API key and JWT schemes beside route metadata.
Runtime context
Surface permissions and middleware in generated docs.
One feature. One bundle. Every runtime surface.
Package handlers, assets, templates, docs, and runtime surfaces near the feature code.
Bundles can be imported from crates, prefixed, layered, validated, and mounted.
Feature-owned
Keep handlers, docs, assets, and surfaces together.
Composable
Merge, prefix, tag, layer, and validate before startup.
Delivery included
Carry assets, templates, services, and migrations.
Modular
Import from another crate without losing APIs or assets.
Built on the best of Rust.
HTTP
Web framework
Persistence
Async SQL toolkit
Runtime
Async runtime
Data
Serialization
Views
Templates
Schemas
JSON Schema
Ready to build something structured and powerful?
Start with a framework that keeps your project organized from the first route to the last background task.