# Volo: a Rust RPC framework split by protocol, not by convenience

> Volo is CloudWeGo's Rust RPC framework, with separate crates for Thrift and gRPC, middleware built on Motore, and a code generator driven by IDL files. Here is what it does, how to start, and where it stops being the right tool.

**cloudwego/volo** — Rust RPC framework with high-performance and strong-extensibility for building micro-services.

- Repository: https://github.com/cloudwego/volo
- Website: https://crates.io/crates/volo
- Stars: 2,627 · Forks: 223
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/cloudwego-volo

## What Volo solves, and for whom

Rust has good HTTP libraries and good async runtimes, but a service-to-service call still needs an interface definition, a generated client and server, and a place to put cross-cutting logic such as discovery or load balancing. Volo fills that gap for two protocols specifically: Thrift and gRPC. The README describes it as a "high-performance and strong-extensibility Rust RPC framework" aimed at microservices, and the repository is organised so that Thrift and gRPC are separate crates rather than one abstraction with protocol switches.

The audience is narrower than the tagline suggests. This is for teams that already have IDL files, either .thrift or .proto, and want the generated Rust types to match the wire contract exactly. If you are writing an internal service that only ever talks to other Rust services and you control both ends, Volo's IDL-first workflow is more ceremony than you need. If you are interoperating with Go, Java or C++ services that already publish Thrift or protobuf definitions, the split is an advantage: volo-thrift and volo-grpc each expose a programming model shaped around its own protocol semantics, which the README gives as the reason for the split.

## Motore, AFIT and the middleware model

The architectural decision that shapes everything else is the middleware abstraction. Volo uses Motore, described in the README as a middleware abstraction powered by AFIT and RPITIT, which are the async-fn-in-trait and return-position-impl-trait features. The practical consequence the README states is that RPITIT lets the framework avoid many unnecessary Box allocations and gives a more ergonomic interface.

What that means for a service author is that middleware is a Service, and service governance features such as service discovery and load balancing can be written as services rather than as separate traits implemented per component. Requests, responses and RPC metadata pass through this chain in a uniform form. The metainfo crate handles transmission of metadata across components, and Pilota provides the Thrift and protobuf implementation underneath. So the data flow is: IDL file, generated code via volo-build, a Service implementation, a Motore middleware stack, and a protocol crate (volo-thrift or volo-grpc) that puts the bytes on the wire.

The trade-off is real. Motore is an external dependency with its own version line, and the workspace pins it at 0.4.1. A middleware abstraction built on recently stabilised language features also inherits their rough edges, and the README does not document what happens when a middleware future is cancelled mid-flight, which is the question that matters most in a load balancer or a rate limiter.

## Installing Volo and generating a first project

The README points at the volo-cli crate as the CLI interface to bootstrap a new project and manage IDL files, and at the getting-started guides on cloudwego.io for Thrift and gRPC. The workspace declares rust-version 1.85.0 and edition 2024, so the toolchain has to be at least that new before anything else works.

Start by confirming the toolchain, then install the CLI from crates.io. The crate name is volo-cli, and the binary it installs is invoked as volo.

```bash
rustup toolchain install 1.85.0
cargo install volo-cli
```

With the CLI on the path, the next step is to generate a project skeleton. The README does not spell out the exact subcommand arguments, so check volo --help before running it; the guides on cloudwego.io cover the Thrift and gRPC variants separately, and the repository keeps a working reference under examples/ with examples/thrift/, examples/proto/ and examples/volo-gen/ directories.

IDL code generation is handled by volo-build, which the README describes as the crate that generates thrift and protobuf code. In a generated project this appears as a build script rather than something you call by hand, and the output crate is what your service imports. The workspace pins pilota at 0.13 and pilota-build at 0.13, so a generated project that resolves to a different Pilota major version will not compile against the examples in this repository.

```toml
[dependencies]
volo = "0.12"
volo-thrift = "0.12"
```

That snippet reflects the release versions in this repository: volo-thrift 0.12.2 was published on 2026-02-02. The gRPC side is on a different line, volo-grpc 0.11.7, published on 2025-09-26, so the two protocol crates do not move in lockstep and you should not assume matching version numbers.

## Where Volo is the wrong choice

The clearest limitation is stated by the project itself: Volo-HTTP is marked "Work In Progress" in the README. The volo-http crate exists in the workspace, but there is no getting-started tutorial for it the way there is for Thrift and gRPC. If your service needs to serve REST or browser traffic today, that crate is not the reason to pick Volo.

The second constraint is the version split. volo-thrift and volo-grpc are separate crates with separate release histories, and the README frames this as deliberate so each protocol gets a programming paradigm that fits its semantics. The cost is that a codebase using both has two dependency lines to track and no single version number that describes the framework.

Third, the performance claims in the README should be read as the project reads them. It gives a QPS figure of 350k under the same test conditions as Kitex, limited to 4C, and says an internal version based on the Monoio runtime reaches 440k. The README also says explicitly that comparing against the Go framework is unfair, that the data is only a reference, and that the project wants to weaken performance comparison. Treat those numbers as the maintainers' own measurement, not as an independent result, and do not pick Volo on the strength of them alone.

Finally, the middleware model assumes you want a Service chain. If your cross-cutting concerns are already solved by a sidecar or a service mesh, you are paying for an abstraction you will not use.

## How Volo differs from Tonic and the rest of the Rust RPC field

The obvious comparison for the gRPC half is Tonic, which is built on Hyper and Tower and is the default choice in most Rust gRPC projects. The difference in approach is the middleware abstraction. Tonic composes with Tower services, so the ecosystem of Tower layers applies directly and the mental model is one many Rust engineers already have. Volo uses Motore instead, which the README ties to AFIT and RPITIT and to avoiding Box allocations in the middleware path. Choosing Volo means adopting a smaller middleware ecosystem in exchange for that.

The Thrift half has a different comparison. The README says the open source community has not produced another mature async Rust Thrift RPC framework, so for Thrift specifically there is little to compare against in Rust. That is an argument for Volo if Thrift is a hard requirement, and it also means fewer people have hit the edge cases before you.

A third point of difference is the IDL toolchain. Volo relies on Pilota for both Thrift and protobuf parsing and generation, so both protocols share one generator. Tonic relies on prost and its own codegen path for gRPC, and does not attempt Thrift at all. If your organisation is standardising on one IDL and one generator across languages, that shared generator is the concrete reason to look at Volo rather than a stylistic preference.

## Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-23. The release cadence visible here is uneven: volo-thrift 0.12.2 and volo-build 0.12.2 both landed on 2026-02-02, while volo-grpc 0.11.7 dates to 2025-09-26. A team depending on gRPC should plan around a slower line than a team on Thrift.

Upgrade cost concentrates in two places. The first is the generated code: because volo-build and Pilota are pinned as a pair, moving the generator means regenerating and recompiling the volo-gen crate, and the workspace here pins pilota at 0.13. The second is the toolchain floor, 1.85.0 with edition 2024, which sets a minimum for every crate in the workspace and therefore for anything that links against them.

On licensing, the README states that Volo is dual-licensed under the MIT license and the Apache License (Version 2.0), with LICENSE-MIT and LICENSE-APACHE in the repository root. The crate metadata lists the licence as "MIT OR Apache-2.0". That is the same permissive pairing most of the Rust ecosystem uses, and it is compatible with closed-source use, but this is a description of what the repository says, not legal advice. The CREDITS.md file lists third party components, and anyone doing a licence audit should read it rather than assume the top-level licence covers everything.

## Conclusion

Adopt Volo if your services already speak Thrift or gRPC and you want the protocol semantics expressed in Rust types rather than hidden behind a generic transport. Do not adopt it if you need a mature HTTP server today, since the README marks volo-http as work in progress, or if your team cannot commit to the 1.85.0 minimum Rust version and edition 2024. Before writing service code, run the volo-cli bootstrap and confirm that the generated volo-gen crate compiles against your pinned pilota version, because that is the seam where IDL changes turn into build failures.

## FAQ

### What is CloudWeGo Volo used for?

It is a Rust RPC framework for building microservices, with separate crates for Thrift and gRPC and a shared IDL code generator. The README describes the goal as a high-performance and strongly extensible framework, and the repository is organised around protocol-specific crates rather than one generic transport.

### Does Volo support gRPC and Thrift in the same project?

Both crates exist in the workspace, volo-grpc and volo-thrift, and they share some components. They are independent frameworks with their own release lines, so a project using both tracks two versions; volo-thrift 0.12.2 was published on 2026-02-02 and volo-grpc 0.11.7 on 2025-09-26.

### What Rust version does Volo require?

The workspace Cargo.toml declares rust-version 1.85.0 and edition 2024. The README also notes that the middleware abstraction is powered by AFIT and RPITIT, which are the language features behind that floor.

## Sources

- [cloudwego/volo on GitHub](https://github.com/cloudwego/volo)
- [License: Apache-2.0](https://github.com/cloudwego/volo/blob/main/LICENSE)
- [Project website](https://crates.io/crates/volo)
- [README](https://github.com/cloudwego/volo/blob/main/README.md)
- [Releases](https://github.com/cloudwego/volo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloudwego-volo