ttrpc is gRPC without the HTTP/2 stack underneath it

The point is binary size and resident memory

ttrpc describes itself in one line as gRPC for low-memory environments, and the reasoning is about density rather than elegance. The documentation says the existing grpc-go project requires a lot of memory overhead for importing packages and at runtime, which is fine for services with low density requirements but becomes a problem when running a large number of services on a single machine, or on a machine with a small amount of memory. The fix is to keep the same gRPC definitions and reduce the binary size and protocol overhead, by eliding the `net/http`, `net/http2` and `grpc` packages and replacing them with a lightweight framing protocol. The claimed result is smaller binaries that use less resident memory with the same ease of use as gRPC. For a build system, a container runtime or a device daemon that supervises dozens of small helper processes, that trade is the whole argument.

The generated services do not speak to ordinary gRPC

The compatibility limit is stated in the same breath as the feature list, and it is the first thing to check before designing around ttrpc. The documentation notes that while the project supports generating either end of the protocol, the generated service definitions will be incompatible with regular gRPC services, because they do not speak the same protocol. That is a different statement from saying ttrpc is not compatible, because the definitions and the coding model are the same and only the wire protocol differs. In practice, both ends of a call have to be ttrpc. A service that must be reachable by an existing gRPC client, by a load balancer that speaks gRPC, or by any third party tooling cannot be moved to ttrpc without also moving those consumers. The framing details are written up in the PROTOCOL.md file at the repository root, which is the document to read before assuming compatibility.

The code is a real implementation, not a wrapper

The repository root is a flat list of Go files that maps closely onto the layers of an RPC stack. `client.go` and `server.go` are the two ends, `channel.go` deals with the connection, `handshake.go` with the exchange that opens it, `codec.go` with encoding, `metadata.go` with call metadata, `interceptor.go` with the hook points, `services.go` with service registration, and `errors.go` with error handling. Streaming has its own files, `stream.go` and `stream_server.go`, and there is a `unixcreds_linux.go` file for Unix domain socket credentials, which tells you that local socket transport is a first class case rather than an afterthought. The `internal/` and `services/` directories hold supporting packages, `cmd/` holds the code generator binary, and `integration/` holds cross component tests. The difference from gRPC that the documentation highlights is that the client and server interface are identical, where in gRPC they are not, and that the Go stdlib context package is used instead.

Generating service code with protobuild or protoc

The usage section is short because the build tooling does the interesting part. The recommendation is to use protobuild, a separate containerd project, to build the protobufs for ttrpc, with the note that this will work with protoc directly if required. The repository reflects that arrangement in its files: `buf.gen.yaml`, `buf.yaml` and `buf.lock` are present for the Buf based generation flow, and there is an `example/` directory containing its own `buf.gen.yaml`, `buf.yaml`, an `example.proto`, a generated `example.pb.go` and a generated `example_ttrpc.pb.go`. That pairing of two generated files is a useful detail, because it shows the split between the ordinary protobuf message definitions and the ttrpc service stubs. The Makefile names the generator binary it builds, `protoc-gen-go-ttrpc`, and the plugin is what turns a service definition into the client and server halves that both share the same interface.

The module still depends on grpc and protobuf

The module file is short and worth reading closely, because it shows what has actually been removed. The module path is github.com/containerd/ttrpc and the Go directive is 1.25.0:

module github.com/containerd/ttrpc

go 1.25.0

The require block lists github.com/containerd/log, golang.org/x/sys, google.golang.org/genproto/googleapis/rpc, google.golang.org/grpc at v1.81.1 and google.golang.org/protobuf at v1.36.11, with github.com/sirupsen/logrus as an indirect dependency. So the elision described in the README is about the runtime stack, not about the dependency graph: grpc and protobuf remain in the module, and the generated code still speaks in protobuf terms. What is not there is the http and http2 machinery, and with it the TLS support that the differences list says the lighter protocol does not require. If your deployment depends on transport security, that is a decision point the documentation forces you to make rather than one it hides.

Two status items are still open

The project keeps a short status list, and it is worth reading before you adopt it. Two boxes are unchecked: adding testing under concurrent load, and verifying connection error handling. Both are the kind of work that is easy to defer and expensive to skip, because the first is about behaviour under many simultaneous calls and the second is about what happens when a peer disappears mid-conversation. The presence of a `stream_full_test.go` alongside `stream_test.go` suggests the streaming path is being worked over, and the `interceptor_test.go`, `metadata_test.go` and `services_test.go` files show that the layers are individually covered, but the project itself flags concurrency as not yet done. For a library whose whole selling point is running many instances in one process, that gap is the one to watch. The project also links the containerd project governance, maintainers and contributing guidelines, since ttrpc is a sub-project rather than a standalone project.

Apache 2.0 and a steady 1.2.x line

ttrpc is a containerd sub-project licensed under the Apache 2.0 license, with the licence text in the repository root, and it inherits containerd's project governance, maintainer list and contributing guidelines from the containerd/project repository. The release history is a steady patch line: v1.2.8 on 2026-03-05, v1.2.9 on 2026-07-08 and v1.2.10 on 2026-09-25, with the last push to the repository on 2026-10-02 and the repository not archived. Nothing in the documentation suggests major version churn, which suits a library that other containerd components depend on, since a stable minor version means the wire protocol and the generated code are not going to shift under you. The Apache 2.0 terms also mean you can vendor, modify and redistribute the library inside a product without the copyleft obligations that would come with a different licence, which matters for an infrastructure component that ends up shipped inside a proprietary appliance.

Editorial conclusion

Teams running a large number of small services on one host, where the memory overhead of grpc-go is the binding constraint, are the audience for ttrpc, and the code layout shows a real implementation rather than a thin wrapper. It is the wrong tool when a service has to talk to an ordinary gRPC client, because the wire protocol is different, and it is a poor fit for a team that needs TLS, HTTP/2 semantics or a large ecosystem. Before adopting it, read PROTOCOL.md and confirm the interoperability boundary in your own deployment, and check the open items in the project status, where concurrent load testing and connection error handling are still unchecked.

Frequently asked questions

Official sources

1. containerd/ttrpc on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases