connect-go: Protobuf RPC over plain net/http

What connect-go replaces, and who it is for

Connect is described in the README as "a slim library for building browser and gRPC-compatible HTTP APIs." You write a Protocol Buffer schema, implement your application logic, and the code generator produces the marshaling, routing, compression and content type negotiation, plus a type-safe client. The audience is Go teams that already keep .proto files and want RPC semantics without adopting gRPC's own HTTP implementation, name resolution or load balancing APIs. The README is explicit that Connect is Protocol Buffers plus the standard library: any package that works with an http.Server, http.Client or http.Handler also works with Connect. That is the whole pitch. If your middleware, tracing or test helpers are written against net/http, they keep working. If you have never used Protobuf, this library is not a shortcut around learning it.

Three protocols on one handler

A generated handler serves gRPC, gRPC-Web and the Connect protocol from the same registration. The README states that streaming, headers, trailers and error details are supported across them, and that gRPC-compatible server reflection and health checks ship as standalone packages (grpcreflect-go and grpchealth-go). The Connect protocol itself is documented as working over HTTP/1.1 or HTTP/2, which is why a curl call is a valid client. The repository layout shows the split clearly: connecthttp/ holds the HTTP transport and mounting helpers, connectgzip/ handles compression, connectproto/ deals with Protobuf-level concerns, and connectinprocess/ provides an in-process path that skips the network. That last package matters for tests, since you can exercise a handler without binding a port. The design decision worth naming: because everything routes through net/http, you inherit net/http's limits as well. Connection pooling, timeouts and h2c configuration are your problem, and the README points at the deployment docs rather than hiding that.

Installing connect-go and serving a first request

The module is connectrpc.com/connect/v2, and go.mod declares go 1.26.0 with google.golang.org/protobuf v1.36.11 as the only direct Protobuf dependency. Add it with the module path exactly as the repository declares it; the /v2 suffix is part of the module name, not a version tag you can drop.

go get connectrpc.com/connect/v2

The README's example registers a generated service on a *connect.Server, mounts that server on an http.ServeMux with connecthttp.Mount, and then enables HTTP/1.1 and unencrypted HTTP/2 on the http.Server. Interceptors are passed to connect.NewServer, and the example passes a Protovalidate server interceptor, which the README calls almost always recommended.

server := connect.NewServer(validate.NewServerInterceptor())
pingv1connect.RegisterPingServiceHandler(server, &PingServer{})
mux := http.NewServeMux()
connecthttp.Mount(mux, server)
p := new(http.Protocols)
p.SetHTTP1(true)
p.SetUnencryptedHTTP2(true)
s := &http.Server{Addr: "localhost:8080", Handler: mux, Protocols: p}

With that running on localhost:8080, the README shows a client built from connecthttp.NewTransport wrapped around http.DefaultClient, then passed to the generated client constructor. The README also warns that http.ListenAndServe and http.DefaultClient are not fit for production and points to the deployment docs for timeouts, connection pools, observability and h2c. Before any of this you need generated code, which comes from a Protobuf plugin; the repository's own buf.gen.yaml and buf.yaml show Buf as the build tool used here, and the README's gRPC curl example installs buf with go install github.com/bufbuild/buf/cmd/buf@latest.

The v2 module is beta, and v1 is not going away

The README's Status section says the v2 module is in beta and will be published on main when released. That is a real constraint on adoption: you are importing a beta module if you write connectrpc.com/connect/v2. The v1 module, connectrpc.com/connect, is described as stable and supported indefinitely, living on the v1 branch. So the honest reading is that two supported import paths exist and they are not interchangeable. A team that needs a stable dependency today can stay on v1 and lose nothing immediately; a team that wants the v2 API shape takes on beta status. There is a migration guide at docs/v2-migration.md and a v2 guide at docs/v2-guide.md, and the Makefile has a testmigrate target that runs the test suite in cmd/connect-go-v2-migrate, which tells you the project treats migration tooling as part of its own build. What the README does not document is a rollback path if a v2 beta change breaks you; the migration guide is the only stated resource, and it is not described as reversible.

When connect-go is the wrong tool

If your clients are browsers and you do not want Protobuf, connect-go adds a schema and a code generation step for no benefit. The README's own curl example sends JSON, but the handler still exists because a .proto was compiled. Teams that only need JSON over HTTP are better served by net/http and encoding/json. Second, if you require a stable module path and cannot accept beta, v2 is off the table until it is released, and the README gives no release date. Third, connect-go does not replace your HTTP server configuration. The README says plainly that http.ListenAndServe and http.DefaultClient are not production-ready, so a team expecting the library to handle connection management, timeouts and observability will be doing that work themselves against the deployment docs. Fourth, the Go version floor is real: go.mod requires go 1.26.0, and the project supports only the two most recent major Go releases. If you are pinned to an older toolchain, this is a blocker before any code is written.

connect-go against grpc-go

The comparison that matters is with grpc-go, and the difference is architectural rather than cosmetic. grpc-go brings its own HTTP/2 implementation, its own name resolution and load balancing APIs, and a client that is not an http.Client. connect-go routes everything through net/http: the README states there is no custom HTTP implementation and no new name resolution or load balancing APIs. Practically, that means your existing http.Handler middleware, your httptest servers and your http.Client instrumentation apply unchanged, and a Connect handler can be mounted in a mux alongside ordinary REST endpoints. The cost is that you give up grpc-go's built-in resolver and balancer ecosystem and configure those concerns yourself, and you accept that the Connect protocol is the project's own specification rather than a standard. For interoperability the repository keeps a conformance suite in internal/conformance with a runconformance make target, which is how the project checks Connect, gRPC and gRPC-Web against each other. If your environment is already all-gRPC and you depend on grpc-go's balancers, switching buys you less than it costs.

Licence, maintenance and upgrade cost

connect-go is offered under the Apache 2.0 licence, per the README's Legal section and the LICENSE file at the repository root. That is a permissive licence with an explicit patent grant, but this is not legal advice and your counsel should review it against your distribution model. On maintenance: the repository is not archived, and the last push was on 2026-09-22, one day before this writing. Releases in the recent line are v1.21.0 (2026-09-08), v1.20.0 (2026-05-20) and the v2.0.0-alpha.1 prerelease (2026-09-11), so the v1 line is still receiving releases while v2 is in alpha and beta. Upgrade cost splits by line. Staying on v1 means following v1 releases on the v1 branch. Moving to v2 means reading docs/v2-migration.md and running the migration tooling under cmd/connect-go-v2-migrate, and because v2 is beta, each alpha or beta bump may change the API. The Makefile pins its own tooling versions (BUF_VERSION 1.69.0, GOLANGCI_LINT_VERSION v2.13.1, GORELEASER_VERSION v2.18.0), which is a useful signal that the project expects contributors to reproduce builds with pinned tools rather than floating ones.

Editorial conclusion

Adopt connect-go if you want Protobuf RPC on the standard library and need gRPC compatibility without a custom HTTP stack. Skip it if you need a stable import path today and cannot pin a beta module, or if a plain JSON REST API is enough. Before starting, read docs/v2-migration.md and docs/v2-guide.md, check whether you import connectrpc.com/connect or connectrpc.com/connect/v2, and confirm your Go version against the two most recent major releases the project supports.

Frequently asked questions

Official sources

1. connectrpc/connect-go on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases