# levkk/rwf: a conventional MVC web framework for Rust, with servers that talk to Django and Rails > Rwf is a MIT licensed Rust web framework built on the classic MVC pattern, shipping an HTTP server, a PostgreSQL oriented ORM, migrations, dynamic templates, authentication with user sessions, middleware, background and scheduled jobs, a REST framework, WebSockets and a CLI, plus the unusual touch of a WSGI server and a Rack server for migrating existing Django, Flask and Rails applications. The project describes itself as beta and looking for early adopters. **levkk/rwf** — Comprehensive framework for building web applications in Rust. - Repository: https://github.com/levkk/rwf - Website: https://rustwebframework.org/ - Stars: 1,062 · Forks: 22 - Language: Rust - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/levkk-rwf ## Classic MVC, on purpose Rwf is a comprehensive framework for building web applications in Rust, written using the classic MVC pattern, the model-view-controller, and it comes standard with everything needed to build fast and secure web apps. The word classic is the positioning statement. A Rust web framework could have taken several shapes, a routing library, a tower of middleware, a compile time HTML dialect, or something built around an actor model. Rwf instead picks the shape that most web developers already know from other languages, and the consequence is that a developer coming from Django or Rails or Laravel recognises the structure immediately, including the parts that are usually implicit. The feature list is where the ambition shows. There is an HTTP server, a user-friendly ORM to build PostgreSQL queries easily, dynamic templates, authentication with built-in user sessions, middleware, background jobs and scheduled jobs, database migrations, a built-in REST framework with JSON serialization, WebSocket support, static files hosting, environment-specific configuration, logging and metrics, and a CLI. Two entries stand out from the rest. The first is the tight integration with Hotwired Turbo for building backend-driven single page applications, which is a specific and opinionated choice about how the browser half of the application should work. The second is a pair of servers, a WSGI server for migrating from Django or Flask applications and a Rack server for migrating from Rails, which is not a feature a framework normally has. ## The quick start is a controller, a route and a server The whole quick start fits in one screen, which is a good sign. ```bash cargo add rwf ``` ```rust use rwf::prelude::*; use rwf::http::Server; #[controller] async fn index() -> Response { Response::new().html("

Welcome to Rwf!

") } #[tokio::main] async fn main() { Server::new(vec![ route!("/" => index), ]) .launch() .await .unwrap(); } ``` The shape is a procedural macro on the handler, a `route!` macro that maps a path to a handler, and a `Server` that takes a list of routes and is launched asynchronously inside a Tokio runtime. The `Response` builder produces the output, here as HTML. Two details are worth noticing. The controller is a plain `async fn` returning a `Response`, so a handler is an ordinary Rust function and anything you can do in an async function you can do in a handler. And the route table is built as a value and passed to the server, which means the routing structure is ordinary Rust data, composable and testable, rather than a macro invocation hidden in a file that only the framework reads. The `rwf::prelude` import is the front door, and the presence of a prelude in a framework crate is a sign that the public surface is designed to be used without a lot of path ceremony. ## The ORM, the migrations and the REST framework The data layer is described as a user-friendly ORM to build PostgreSQL queries easily, and the persistence story is complete rather than partial, because database migrations are a first class feature. That combination is the one that decides whether a framework is usable for a real application. An ORM without migrations means your schema history lives in someone's head, and migrations without an ORM means your queries are strings. Rwf has both, and the examples directory has separate `examples/orm` and `examples/rest` entries, so the intended usage of each is documented as working code rather than prose. The REST framework is built in, with JSON serialization, which means a service style API is not something you bolt on. The `examples/rest` example is a separate crate in the workspace, so it is compiled and tested with the framework rather than being a snippet that drifts. The `examples/` directory is the documentation in practice, and it is broad. There are directories for `auth`, `background-jobs`, `callbacks`, `django`, `dynamic-templates`, `engine`, `files`, `middleware`, `oidc`, `openapi`, `orm`, `quick-start`, `rails`, `request-tracking`, `rest`, `scheduled-jobs`, `static-files`, `turbo` and `users`. That list also tells you what the framework is reaching for. `oidc` and `openapi` mean standards compliance for identity and for the API description, `callbacks` and `request-tracking` are lifecycle concerns, and `engine` suggests a pluggable rendering or execution layer. Each of those is a topic that would be several crates in a hand rolled stack. ## Jobs, sessions and the Turbo decision Background jobs and scheduled jobs are separate features, which is the right split. A background job is work you enqueue, a scheduled job is work on a timer, and conflating them is what makes job systems in other languages hard to reason about. Both have their own example crates, `examples/background-jobs` and `examples/scheduled-jobs`. Authentication comes with built-in user sessions, which is the piece most frameworks either do badly or leave entirely to you. The `examples/auth` and `examples/users` directories cover it, and there is an `examples/oidc` for the case where your identity comes from outside. The most opinionated choice is the Hotwired Turbo integration, described as tight, for building backend-driven single page applications. The idea is that the server returns HTML fragments and the browser side swaps them in, so the application is a single Rust server rendering views, with JavaScript only where it earns its place. It is a genuine alternative to shipping a JavaScript framework and an API layer, and it is a coherent position for a framework that also ships a REST framework, since the two coexist rather than compete. `examples/turbo` is the example to read if this is the part you are considering, because it shows the pattern end to end rather than describing it. The remaining infrastructure features are the ones you would otherwise assemble yourself: middleware, static files hosting, environment-specific configuration, and logging and metrics, the last of which tells you the framework is intended for something you would run in production rather than a demo. ## The migration servers are the unusual part The last two entries in the feature list are the ones that set Rwf apart from every other Rust web framework. There is a WSGI server for migrating from Django or Flask apps, and a Rack server for migrating from Rails. Both have example directories, `examples/django` and `examples/rails`. Read those two bullets carefully, because they are not about interoperability in the abstract. They are about running a Python or Ruby application against a Rust web server, which is how a rewrite usually starts in practice. A team that wants the performance and the type safety of Rust does not rewrite a Django application in one go, it puts the new code behind the old one and moves a route at a time. A framework that ships servers speaking WSGI and Rack is designed for that strangler pattern rather than for a clean sheet rewrite. The repository layout backs this up. There is a `rwf-ruby/` crate, and the Cargo workspace deliberately excludes `examples/rails`, `rwf-ruby`, `examples/django` and `rwf-fuzz` from the default member list, so those parts are built separately and the main workspace stays buildable without a Ruby or Python toolchain. The excluded set is a tell: it is exactly the set that needs something outside Rust. There is also a `rwf-fuzz/` directory and a `rwf-admin/` directory, an admin interface crate, and a `rwf-macros/` crate holding the procedural macros that make the `#[controller]` and `route!` syntax work. ## Beta, and what the release history says The status section is one paragraph and it is worth reading as carefully as the feature list. Rwf is in beta and looking for early adopters. Most features are in a good state and documentation is usable. Three claims, and they are different in kind. The first, that it is beta, is a statement about the author's own standard. The second, that most features are in a good state, is a statement about the internals. The third, that the documentation is usable, is a statement about the gap between what the code does and what is written down, and it is the one that should govern your expectations. The release history is consistent with that. The tags are v0.1.15 on 2024-11-29, v0.2.0 on 2024-12-01 and v0.2.1 on 2024-12-05, three releases in a week at the end of 2024, and the last push to the repository was on 2026-04-14. The published crate version is about sixteen months behind the head of the branch, which is exactly the profile of a project that is used by a small number of early adopters pulling from git rather than from crates.io. For an adopter that is a workable arrangement, and for anyone else it is a risk. The way to size that risk is in the examples, since seventeen of the nineteen example crates covering auth, jobs, ORM, REST, Turbo, OpenAPI and OIDC are compiled as part of the workspace and therefore have to keep working as the framework changes. ## Where Rwf is the wrong choice The first wrong case is a project that needs a settled ecosystem. Rwf is a beta framework whose published version stopped in 2024, and the dependency tree of a web application is where a small ecosystem hurts most, because a framework is only as good as the crates it can pull in for the things it does not do. The second is a team that has no patience for a framework's opinions. Rwf has opinions, and they are strong ones, the classic MVC structure, a PostgreSQL oriented ORM, and Hotwired Turbo for the browser half. That is a coherent stack, and if you agree with it you will move fast, but each of those is a decision you are inheriting rather than making. The third is a service that is mostly API. Rwf ships a REST framework and a Turbo integration, which are two different answers to the same question about what the browser does. If your application is a JSON service consumed by mobile clients, the parts you would use are the server, the ORM and the migrations, and the parts you would ignore are the templates, the sessions and the Turbo story. The fourth is a team that needs long term support guarantees rather than a maintained repository. The licence is MIT, which is permissive but still requires keeping the copyright notice, and the maintenance is a single author looking for early adopters, which is a different thing from a project with a foundation behind it. The way to evaluate it is cheap. The examples are the specification, they are real crates in the workspace, and reading `examples/quick-start`, `examples/orm` and `examples/turbo` will tell you in twenty minutes whether the framework's shape matches the application you have in mind. ## Conclusion Adopt Rwf if you are building a server rendered Rust application and want a batteries included MVC structure with an ORM, migrations, sessions and jobs rather than assembling them from separate crates, and if you are willing to work with a beta framework whose documentation is described as usable rather than complete. Do not adopt it for a project that needs a stable, widely adopted framework with a large dependency ecosystem, since the release history stops in December 2024 and the project is explicitly looking for early adopters. Verify first that the features you need are in the examples directory, that the ORM covers your database, that the license is MIT for your use, and that the last push, on 2026-04-14, still reflects the state of the code you are about to depend on. ## FAQ ### What is Rwf and what does it include? Rwf is a MIT licensed Rust web framework written in the classic MVC pattern. It includes an HTTP server, an ORM for building PostgreSQL queries, dynamic templates, authentication with built-in user sessions, middleware, background and scheduled jobs, database migrations, a REST framework with JSON serialization, WebSockets, static files hosting, Hotwired Turbo integration, environment-specific configuration, logging and metrics, and a CLI. ### How do I add Rwf to a Rust project and start a server? Add it with `cargo add rwf`, then define a handler with the `#[controller]` macro, map it with `route!` and launch a `Server` with the route list inside a Tokio runtime, awaiting the launch and unwrapping the result. ### What is the status of Rwf? The project states that Rwf is in beta and looking for early adopters, that most features are in a good state and that the documentation is usable. The release tags are v0.1.15, v0.2.0 and v0.2.1 from the end of November and early December 2024, and the last push to the repository was on 2026-04-14. ### What is the WSGI and Rack server support in Rwf for? Rwf ships a WSGI server for migrating from Django or Flask applications and a Rack server for migrating from Rails, with example directories for each. The workspace excludes the Rails, Ruby and Django examples from its default members, so they are built separately from the Rust-only crates. ### How can I learn how Rwf works? The `examples/` directory holds nineteen example crates covering auth, background jobs, callbacks, dynamic templates, engine, files, middleware, OIDC, OpenAPI, ORM, quick start, request tracking, REST, scheduled jobs, static files, Turbo and users, and the repository also has ARCHITECTURE.md for a tour of the code, CONTRIBUTING.md and a ROADMAP.md. ## Sources - [levkk/rwf on GitHub](https://github.com/levkk/rwf) - [License: MIT](https://github.com/levkk/rwf/blob/main/LICENSE) - [Project website](https://rustwebframework.org/) - [README](https://github.com/levkk/rwf/blob/main/README.md) - [Releases](https://github.com/levkk/rwf/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/levkk-rwf