xitca-web is a Rust web stack that lets you opt out of macros

A framework that is also its own HTTP library

The positioning is unusual enough to be worth stating first. Most Rust web frameworks sit on top of an HTTP implementation that someone else maintains, and the framework's job is routing, extractors and middleware. xitca-web provides its own HTTP library, async IO abstraction, TLS integration and a database driver, all in one package, and the stated reasons are a low memory footprint, less synchronisation overhead between threads, a very small dependency tree and good interoperability with other async frameworks such as tokio and async-std as well as with crates like Tower and http. The advantage of owning the whole stack is that the layers can be tuned together. The cost is that you now depend on this project's view of the HTTP stack rather than on the ecosystem's most-used one.

The macros are optional, and that is the point

The FAQ section explains the design in one long paragraph, and the last clause is the one that sets it apart. The framework is meant to offer a simple and compact code base with an easier to understand and adoptable API both internally and externally, and to give the user the choice to opt out of macro usage, which the README says can greatly improve build and compile times by eliminating the extra proc-macro build step. That is a real, measurable cost in Rust, since a proc-macro crate has to be compiled before anything that uses it can be, and the compile is usually not incremental in the way ordinary code is. A framework that lets you write plain functions as handlers and then register them by hand is easier to debug and easier to step through.

The quick start is a dozen lines and one dependency

The example in the README is the whole introduction. You import the handler service helper, the logger middleware, the route combinator and the app type, write an async function that returns a static string, and then build the app:

use xitca_web::{handler::handler_service, middleware::Logger, route::get, App};

async fn index() -> &'static str {
    "Hello world!!"
}

fn main() -> std::io::Result<()> {
    App::new()
        .at("/", get(handler_service(index)))
        .enclosed(Logger::new())
        .serve()
        .bind("localhost:8080")?
        .run()
        .wait()
}

The dependency is one line in the Cargo.toml, and the logger feature is named explicitly:

xitca-web = { version = "*" , features = ["logger"]}

After that, `cargo run` starts the server on the local port 8080 and the index responds with the hello world message. The structure of the code is the argument for the design: the app is a value that is built by chaining, the route is attached with `at`, the middleware is applied with `enclosed`, and the server is bound and then run. There is a `hello-world` example in the examples directory that matches this.

Twenty crates, and the feature list spans most of HTTP

The workspace manifest lists the members, and they explain the scope. There are the core pieces, `client`, `codegen`, `http`, `io`, `postgres`, `postgres-codegen`, `router`, `server`, `service`, `tls` and `web`. Then the protocol and body crates, `http-body`, `http-encoding`, `http-file`, `http-multipart`, `http-rate`, `http-grpc` and `http-ws`, plus a `tokio-uring` crate. The feature list matches: HTTP/1.x, HTTP/2 and HTTP/3, request routing with optional opt-in macros, full tokio compatibility, cross crate integration with Tower, client and server WebSockets, transparent content compression and decompression for br, gzip, deflate and zstd, multipart streams, static assets, SSL support through Xitca-tls or rustls, and middlewares such as Logger and Tracing. The rust version is pinned in the workspace package section at 1.98, and the README states that the latest release supports 1.98 and above.

Safe Rust is the stated goal, with one crate named otherwise

The README calls the project a HTTP library and web framework written in 100% safe Rust with zero-copy serialization and deserialization support, and the FAQ gives memory safety as the primary reason the project exists. The workspace members include a crate named `unsafe_collection`, published as `xitca-unsafe-collection`, which is worth pausing on. The name signals a deliberate boundary: there is a place where unsafe code is confined, rather than unsafe scattered through the framework. The README does not say whether that crate is enabled by default, so anyone whose threat model depends on the safe Rust claim should check the crate itself and the features it is tied to. The `codegen` crate is separate too, which is consistent with the macros being opt-in.

The examples are a catalogue of protocol combinations

The examples directory is the best documentation in the repository, and it reads like a test matrix. There are examples for authentication, certificates, compression, cookies, dependency injection, error handling, file serving, gRPC, the hello world case, io-uring with HTTP/2 and io-uring alone, macros and non-macro forms, multiple HTTP services in one process, multipart, streaming, synchronous code, Tower integration through tower-http, Unix sockets, WASI, and WebSockets. The examples and the macros pair is the one that matters most for the compile-time argument, since it shows both shapes of the same application side by side. There is a `codegen` directory in the workspace and a `supply-chain/` directory at the top level, which is where projects record the provenance of their dependencies.

Stability is the caveat, and it is stated plainly

Under the quick start there is a warning that deserves to be read before anything else. The project is still not stable, so breaking changes can appear at any time. That warning is in tension with a feature list that includes three HTTP versions, gRPC, WebSockets and TLS, and it is the main thing an adopting team has to weigh. The rest of the repository suggests a small but active group: a CHANGES.md file at the top level for release notes, a `test/` crate in the workspace members, a `rustfmt.toml`, and a `.cargo/` directory for cargo configuration. The last push to the main branch was on 2026-10-13, and the crate has no GitHub releases, so the published versions live on crates.io and docs.rs rather than in the repository's release history.

Editorial conclusion

Adopt xitca-web if you want a Rust web stack that owns its HTTP, TLS and async layers in one place and you would rather skip the proc-macro step that other frameworks impose, since the macros are opt-in rather than mandatory. Do not adopt it for production work you cannot afford to revisit often, because the README states plainly that the project is still not stable and that breaking changes can appear at any time. Verify first that your Rust toolchain is 1.98 or newer, and read the workspace member list before you start, since the framework spans twenty-one crates and you will need to know which of them your application actually depends on.

Frequently asked questions

Official sources

1. HFQR/xitca-web on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README