# Kitex: a Go RPC framework built on Netpoll and Thrift > Kitex is CloudWeGo's Go RPC framework for microservices, with Thrift, Kitex Protobuf and gRPC messaging, TTHeader and HTTP2 transports, and a code generator. It suits Go teams that want Netpoll and pluggable governance; it is the wrong choice if you need a polyglot mesh or have not settled on Thrift or Protobuf IDL. **cloudwego/kitex** — Go RPC framework with high-performance and strong-extensibility for building micro-services. - Repository: https://github.com/cloudwego/kitex - Website: https://www.cloudwego.io/docs/kitex/ - Stars: 8,052 · Forks: 916 - Language: Go - License: Apache-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/cloudwego-kitex ## What Kitex solves, and who it is written for Kitex is a Go RPC framework for building microservices. The README frames the target plainly: if performance and extensibility are the main concerns when you develop microservices, Kitex can be a good choice. That sentence is the whole positioning. It is not a service mesh, not a proxy, and not a multi-language IDL compiler. It is a library you import into a Go binary, plus a code generator that turns an interface definition into client and server stubs. The audience is therefore narrow and specific. You are writing Go services. You already have, or are willing to write, interface definitions in Thrift or Protobuf. You care about the network layer enough to accept a dependency on Netpoll, which the README describes as a high-performance network library that offers a significant performance advantage over go net. If any of those three conditions is false, the framework's main advantages do not apply to you, and a plain net/http service or a different RPC stack will cost less to operate. The repository layout reflects that scope. Top-level directories include client/, server/, transport/, tool/ and internal/, with pkg/ holding shared code. There is no directory for bindings in other languages, which is consistent with a Go-only framework. ## How the pieces fit: protocols, transports and message types Kitex separates three concerns that are often conflated. The messaging protocol decides how a request and response are encoded: the initial release supports Thrift, Kitex Protobuf and gRPC. Kitex Protobuf is described in the README as a Kitex custom Protobuf messaging protocol with a protocol format similar to Thrift, so it is not the same wire format as gRPC even though both carry Protobuf payloads. The transport protocol handles service governance concerns: TTHeader and HTTP2. TTHeader can be used in conjunction with Thrift and Kitex Protobuf. That compatibility note matters, because it means the transport and messaging choices are not independent, and the documentation does not present a full matrix of every combination. On top of those, Kitex supports three message types: PingPong, One-way and Bidirectional Streaming. One-way currently only supports the Thrift protocol. Again, the constraint is stated as a current limitation rather than a design principle, so it is worth rechecking against the release you install. The extensibility claim is backed by interfaces rather than by a plugin runtime. The README says Kitex provides many interfaces with default implementations for users to customize, and lists extension points including middleware, suites, service registry, service discovery, custom load balancers, monitoring, logging, codec, transport module, transport pipeline, metadata transparent transmission and diagnosis. Most governance features (registry, discovery, load balancing, circuit breaker, rate limiting, retry, monitoring, tracing, logging, diagnosis) come with defaults, and you opt in to the ones you want. ## Installing Kitex and generating a first service Kitex is consumed as a Go module, so the first step is a module with a Go toolchain. The repository's go.mod declares go 1.20, which is the floor for the main branch as published. The README points to the Getting Started page at cloudwego.io for the walkthrough, and to the Code Generation section for the generator itself. Add the framework to an existing module: ```bash go mod init example.com/hello go get github.com/cloudwego/kitex ``` The README does not print a version pin in the install snippet, so the version you receive is whatever the module proxy resolves. The recent releases listed for this repository are v0.16.0, v0.16.1 and v0.16.2. Code generation is the part that distinguishes Kitex from a bare RPC library. The repository has a tool/ directory and the README describes built-in code generation tools that support generating Thrift, Protobuf and scaffold code. The generator is driven from an IDL file, so the practical first step is writing or obtaining a .thrift or .proto definition, then running the generator to produce client and server code. The README's Code Generation section links to a Code Generation Tool page and a Combined Service page; it does not reproduce the generator invocation in the README itself, so treat the linked page as the source of truth for flags. Before writing application code, confirm which protocol and transport pair you are targeting. The README states that TTHeader can be used in conjunction with Thrift and Kitex Protobuf, and that One-way messaging is limited to Thrift. Those two sentences constrain the option combination you pass when constructing a client or server. ## Where Kitex is the wrong tool The clearest limitation is language. Kitex is a Go framework. A microservice fleet that mixes Go with Java, Python or Node cannot use Kitex as a common RPC layer, because there are no bindings for those languages in the repository. The topics list includes grpc, and Kitex does support a gRPC messaging protocol, but that is a wire-format compatibility story, not a cross-language SDK story. If interoperability with non-Go services is your primary requirement, gRPC with its own language stubs is the more direct answer. A second constraint is that the protocol surface is not uniform. One-way messaging only supports Thrift. TTHeader is described as usable with Thrift and Kitex Protobuf, which leaves the position of TTHeader with gRPC unstated in the README. Anyone planning a mixed-protocol deployment should read the reference documentation on transport protocols rather than assume the combinations compose freely. Third, the README's performance section is honest about its own limits: performance benchmark can only provide a limited reference, and in production there are many factors that can affect actual performance. The repository points to a separate kitex-benchmark project rather than publishing headline numbers. That is a reasonable stance, but it means you cannot size the benefit from the README alone. The advantage claimed over go net comes from Netpoll, and whether that advantage materialises depends on your workload, your connection patterns and your serialization choice. Finally, the extension points are interfaces with default implementations. That is a smaller commitment than a plugin system, but it also means that anything beyond the defaults, such as a registry or a tracing backend, comes from the separate kitex-contrib repository, which the README describes as a partial extension library that users integrate through options. ## Kitex compared with plain gRPC in Go The obvious alternative for a Go microservice team is google.golang.org/grpc with Protobuf. The difference is not the wire protocol, since Kitex supports a gRPC messaging protocol; it is where the framework draws its boundaries. With plain gRPC in Go, the transport is the standard library's HTTP/2 implementation, the code generator is protoc with the Go plugin, and service governance (load balancing, retries, circuit breaking, discovery) is either left to the application or supplied by the surrounding infrastructure, commonly a sidecar or a service mesh. The gRPC stack is language-neutral by design, and its ecosystem spans many runtimes. Kitex inverts that. It owns the transport through Netpoll, owns the code generator through its own tooling, and ships governance modules as in-process extensions with defaults. The README lists registry, discovery, load balancing, circuit breaker, rate limiting, retry, monitoring, tracing, logging and diagnosis as integrated modules. The trade is reach for depth: you get a coherent in-process story for Go services, and you give up the multi-language reach and the protoc-centric tooling that most teams already know. A second alternative worth naming is Thrift's own Go library, since Kitex supports Thrift as a messaging protocol. Kitex's Thrift support is one option among several in a framework that also speaks Kitex Protobuf and gRPC, with its own generator and governance layer on top. Choosing Kitex for a Thrift service means adopting that layer as well, not just the IDL. ## Maintenance, versioning and licence The repository is not archived, and the last push was on 2026-09-15, which is recent relative to the current date. The recent release tags are v0.16.0 and v0.16.1, both dated 2026-04-05, and v0.16.2 dated 2026-05-08. The version numbering is still in the v0.x range, which in Go module terms means no compatibility promise beyond what the maintainers choose to honour; go.mod itself declares go 1.20, so the minimum toolchain is explicit even though the module version is not yet v1. Upgrade cost is mostly the cost of moving the generator output and the extension options together. The generator comes from the same project, so a framework upgrade and a regenerated stub set are coupled. The extension libraries live in kitex-contrib and are integrated through options, so a framework bump can require matching bumps there. The README does not document a rollback procedure, and it does not publish a compatibility matrix for framework versions against contrib versions. That gap is the main practical risk in an upgrade. The licence is Apache-2.0, stated in the README's License section and present as a LICENSE file at the repository root. The README also notes that the licences of third party dependencies are explained in a licenses file in the repository. Apache-2.0 is a permissive licence with an explicit patent grant and notice requirements; if you redistribute Kitex inside a product, read the NOTICE file and the licenses directory rather than assuming the single licence line covers everything. That is a statement about what the repository contains, not legal advice. ## Conclusion Adopt Kitex if your services are written in Go, your interfaces are already described in Thrift or Protobuf IDL, and you want Netpoll under the transport plus governance hooks you can swap out. Do not adopt it if most of your fleet is Java, Python or Node, because the framework ships for Go and the extension ecosystem is Go only. Before committing, verify three things against the current repository: that the generator emits code for your exact IDL dialect, that the specific kitex-contrib integration you need (registry, tracing, monitoring) still exists for your version, and that the transport option you plan to use (TTHeader or HTTP2) is compatible with the messaging protocol you picked. The README states that Thrift and Kitex Protobuf work with TTHeader, so a mismatch there is discovered at runtime, not at compile time. ## FAQ ### What is Kitex in the cloudwego/kitex project? It is a Go RPC framework for building microservices, described in the README as high-performance and strong-extensibility. It supports Thrift, Kitex Protobuf and gRPC messaging protocols, TTHeader and HTTP2 transports, and ships a code generator for Thrift, Protobuf and scaffold code. ### What does the name Kitex stand for? The README gives a pronunciation, Kitex [kaɪt'eks], but it does not expand the name into words or explain an acronym. The repository offers no etymology, so the meaning of the name is not documented. ### Does Kitex support gRPC and Protobuf? Yes. The README lists Thrift, Kitex Protobuf and gRPC as supported messaging protocols, and notes that Kitex Protobuf is a custom Protobuf messaging protocol with a format similar to Thrift rather than the gRPC wire format. The code generator supports generating Thrift, Protobuf and scaffold code. ### Which Go version does Kitex require? The go.mod file in the repository declares go 1.20, which is the minimum toolchain version for the main branch as published. The README does not restate a version requirement in prose. ### Is Kitex limited to one messaging type? No. The README states that Kitex supports PingPong, One-way and Bidirectional Streaming, with the constraint that One-way currently only supports the Thrift protocol. The word currently suggests the limitation is expected to change. ### Under what licence is Kitex distributed? Apache License, version 2.0, per the README's License section and the LICENSE file at the repository root. The README adds that the licences of third party dependencies are explained in a separate licenses file. ## Sources - [cloudwego/kitex on GitHub](https://github.com/cloudwego/kitex) - [License: Apache-2.0](https://github.com/cloudwego/kitex/blob/main/LICENSE) - [Project website](https://www.cloudwego.io/docs/kitex/) - [README](https://github.com/cloudwego/kitex/blob/main/README.md) - [Releases](https://github.com/cloudwego/kitex/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloudwego-kitex