grpcui: a browser UI for gRPC servers, installed in one command

What grpcui is for, and who ends up using it

gRPC APIs are awkward to poke at by hand. A REST endpoint accepts a JSON body over curl; a gRPC method wants a length-prefixed protobuf message on HTTP/2, and the field numbers are not in the URL. The usual workaround is grpcurl, which is fine once you already know the exact message shape and the exact flag set. grpcui targets the earlier moment: you know a server exists at host:port, you want to see which services it exposes, and you want to fill in a request without reading a .proto file line by line.

The README frames the tool as "sort of like Postman, but for gRPC APIs instead of REST." That comparison is about the interaction model, not the feature set. Postman keeps a collection of saved requests; grpcui builds a form per method from the schema and sends one request when you click Invoke. The audience is backend engineers debugging their own service, QA staff who need to exercise a method against a staging deployment, and anyone who has to demonstrate a gRPC API to somebody who will not install a Go toolchain. Two library packages ship in the same repository for teams that want the form embedded rather than run as a standalone binary.

How the schema gets from the server into the form

Everything in grpcui hangs off one decision: where the descriptor set comes from. The README lists three sources. The preferred one is server reflection, where the server answers a reflection RPC and hands back its own descriptors. The second is .proto source files passed on the command line. The third is protoset files, which the README describes as compiled descriptors produced by protoc.

That schema is not just for display. The README states that the same schema is what transforms JSON request data into binary encoded protobuf on the wire. So the form, the JSON tab and the encoder all read from one descriptor set; if the descriptor set is wrong or stale, the request you build will be wrong in a way the UI cannot detect. This is the sharpest constraint in the design. A server without reflection and without a reachable .proto file leaves you with nothing to point the tool at.

The UI itself is a dynamic HTML table. Each row is a field, the first column names the field and its type, the second shows cardinality (a checkbox for optional fields, add and delete buttons for repeated ones), and well-known types such as google.protobuf.Timestamp, oneofs and maps get dedicated handling. A second tab exposes the raw JSON request body for pasting large payloads. A third tab holds the response, disabled until you click Invoke, and after the call it shows headers, trailers and the response body as an HTML table.

Installing grpcui and sending a first request

The README gives two install paths. On macOS or Linux, Homebrew:

brew install grpcui

If you already have Go, the module path works from anywhere:

go install github.com/fullstorydev/grpcui/cmd/grpcui@latest

The README notes this lands the binary in the bin sub-folder of $GOPATH, so that directory needs to be on your $PATH. There is also a make install target for a checkout of the repository, and if you would rather not install at all, the README shows running it straight from source:

go run ./cmd/grpcui/grpcui.go -plaintext localhost:9019

Running the binary prints the URL to open. The README's own example output looks like this:

grpcui -plaintext localhost:12345
gRPC Web UI available at http://127.0.0.1:60551/...

Note the port in that URL. It is not 12345, which is the gRPC target; it is the ephemeral port the tool's own HTTP server picked, and the README says the -port flag exists precisely to pin it. If you need a stable address, pass -port explicitly. Once the page loads, pick a service and method from the two listboxes at the top, fill in the generated form or paste JSON into the second tab, then click Invoke at the bottom and read the response tab. A Dockerfile is in the repository and its entrypoint already sets -bind=0.0.0.0, -port=8080 and -open-browser=false, which is the shape you want for a container.

Where grpcui breaks down

The streaming limitation is stated plainly and it is the one that bites. grpcui supports streaming methods, but the README says it requires you to construct the entire stream of request messages all at once and then renders the entire resulting stream of response messages all at once. For a server-streaming call that returns a few hundred rows, that is tolerable. For a bidirectional stream where the server's next message depends on what you send next, it is not usable, and the README says so directly by contrasting it with grpcurl, which can interact with bidirectional streams.

Schema availability is the second failure mode. No reflection, no .proto, no protoset means no form. In production environments where reflection is deliberately disabled, that is the normal state, and you will be carrying a protoset around.

The third issue is exposure. grpcui runs an HTTP server, and the Dockerfile in the repository binds it to 0.0.0.0 on port 8080. Anything that server can reach, the UI can reach, because the UI is a proxy for arbitrary gRPC calls with arbitrary metadata. Treat the port as you would treat an open admin console, and check what the default bind address is in the build you install rather than assuming it is loopback.

grpcui against grpcurl and Postman

grpcurl is the obvious alternative and the README treats grpcui as an extension of it. The difference is not capability, it is the shape of the work. grpcurl is a command-line interface where you write the JSON body and the flags yourself, which makes it scriptable and repeatable in CI. grpcui generates the form from the descriptor set and lets you discover methods you did not know existed. If you are writing a test that must run unattended, grpcurl is the right tool and grpcui adds nothing. If you are exploring an unfamiliar service, the reverse holds.

Postman is the other comparison, and the README makes it explicitly. The README uses Postman only to describe the interaction model. grpcui builds its form from the descriptor set, at the cost of its dependence on a schema source and its buffered stream handling.

Maintenance, releases and the MIT licence

The repository is not archived and the last push was on 2026-11-02, with v1.5.4 released on 2026-09-02 and v1.5.3 shortly before it. The project is written in Go despite the JavaScript in its primary language field, which reflects the amount of browser-side code in the form; go.mod declares go 1.26.0 and pins grpcurl v1.9.4, protoreflect v1.19.0 and grpc v1.83.2. Upgrade cost is mostly Go toolchain cost. The README warns that compile errors can come from out-dated dependencies and points at make updatedeps, which runs go get -d -v -t -u -f ./... followed by go mod tidy. If you vendor grpcui into a larger module, that indirect dependency list is what you inherit.

The licence is MIT. That permits commercial and closed-source use, and it requires the copyright notice and permission notice to travel with copies or substantial portions of the software. It offers no patent grant and comes with no warranty. If you embed the standalone handler in a product, the notice obligation applies to your distribution, so route it through whoever handles your third-party notices rather than deciding it yourself.

Editorial conclusion

Use grpcui when you need to poke at a gRPC service interactively and you can get its schema, either through server reflection or by handing the tool .proto or protoset files. Skip it for load testing, for scripted regression runs, and for bidirectional streams where you need to react to each message as it arrives, because the documentation states the whole request stream is built at once and the whole response stream is rendered at once. Before adopting it in a shared environment, check what the -bind flag defaults to in the version you install and whether the HTTP endpoint it exposes is reachable by anyone else on the network.

Frequently asked questions

Official sources

1. fullstorydev/grpcui on GitHub
2. Issues
3. License: MIT
4. README
5. Releases