Where Kratos fits
Kratos is worth evaluating when the same service contract needs HTTP and gRPC interfaces. Its README describes Protobuf-based generation, a unified transport layer, and middleware for recovery, logging, validation, tracing, metrics, and authentication. Those components give a team a shared framework for service conventions. A small HTTP-only application may have little reason to take on that generation workflow.
The README also separates core interfaces from optional contrib integrations for registries, configuration stores, encodings, and observability. These are documented capabilities, not integrations exercised by our sandbox run.
What our recorded run establishes
Our run took place on September 28, 2026 at commit 668db92c2c001e9552594ba5a8aede8456af6d7e, whose recorded commit date is June 26, 2026. No new execution was performed for this correction.
| Recorded step | Rounded duration | Observed scope |
|---|---|---|
| Dependency/setup | 27 seconds | Exit 0; summary records 53 dependencies; retained output shows a Go toolchain download |
| Build-labelled step | 36 seconds | Exit 0; retained tail is vet-exit:0; binary output is not established |
| go test | 33 seconds | Exit 0; parser records 88 successful package results, 0 failed package results, and 2 packages without test files |
The 88 figure is a recorded package-result summary, not an individual test-case count. The retained output includes repeated package lines, and no complete-log reconciliation established exhaustive unique coverage. The three rounded durations add to 96 seconds, while the harness records 103 seconds for the overall run.
The configured image was golang:1.24-bookworm, with 3 CPUs and 8 GB of RAM. The setup tail says go: downloading go1.25.0 (linux/amd64). That download prevents using the image name as proof that this revision builds with Go 1.24. The retained record does not separately identify the toolchain used by every later command.
The scan recorded 465 files, 45,874 source lines, a 6.5 MB checkout, and 6 CI workflows. It detected no Dockerfile, Compose file, or tests directory. These are checkout observations; the successful package results show why a missing tests directory should not be read as missing tests.
This run does not establish an installed CLI, a working generated service, database connectivity, request latency, throughput, or deployment readiness. The dependency count is not an audit coverage count, and no security audit result is supplied.
The README and current quick start use different entry paths
The README lists Go 1.25 or later, protoc, and protoc-gen-go, followed by CLI installation. Its short service flow uses kratos new, module tidying, and service startup. The fuller flow adds a .proto file, generates client and server code, runs go generate, and starts the application.
The current quick start begins with the maintained project template instead. It explicitly says the project can be used without the CLI. The documented template includes HTTP and gRPC servers, Protobuf APIs, Wire, Ent, tests, and an OpenAPI document.
That template has a wider setup scope: Go 1.25.7 or a compatible supported release, Git, Make, and MySQL for its default runtime configuration. Its initialization installs Buf and Wire with moving latest versions; the documentation recommends pinning command versions for repeatable CI. Renaming the module also requires replacing the template's old imports.
For an adoption trial, generate and test the chosen template, configure its database, then create and retrieve a Todo through the documented endpoints. The documentation warns that process startup alone does not prove database connectivity. Our repository run did not perform those application checks.
V3 requires an application migration
The v3.0.0 release identifies commit 668db92 and lists the update to v3 modules as a breaking change. The migration guide changes imports from github.com/go-kratos/kratos/v2 to github.com/go-kratos/kratos/v3, but the work extends beyond imports.
Applications must choose their JSON codec explicitly, migrate logging to log/slog, move JWT middleware imports to contrib, review custom circuit breakers, replace direct HTTP binding imports, and regenerate generated code. The guide calls for application tests and lint checks before shipping. A successful test step in the framework repository cannot substitute for those checks in a migrated service.
Configuration and logging reports need revision-specific checks
Issue 3881 reports that direct boolean environment overrides failed during configuration scanning in v3.0.0. The supplied issue extract shows it closed as completed through #3891 on October 20, 2026. It should therefore not be described as an open issue. Closure alone does not establish which published version contains the change or whether every reported configuration case is covered. Verify the behavior against the revision you intend to deploy.
Issue 3886 remains open in the supplied extract, with a linked PR, #3892. Its reporter describes duplicate error text in the error and stack attributes and error-level logging for all non-nil errors, including expected client errors in v3.0.0. These are upstream reports, not failures reproduced in our run. Teams whose alerting depends on log levels should check representative error responses in their own service.
How to read the ratings
The scores are editorial judgments about the supplied evidence, not benchmark results or adoption measurements. The scale is 1 for substantial documented obstacles or insufficient evidence, 2 for a partial basis with major verification gaps, 3 for a usable evaluation path with material caveats, 4 for detailed relevant guidance or demonstrated scope with narrower gaps, and 5 for unusually complete evidence across the intended use. Unknown production adoption or compatibility does not earn a high score.
Setup receives 3/5 because the template has a documented path but requires database and generation tooling that our run did not verify. Documentation receives 4/5 for concrete template, endpoint-check, and migration instructions. Community receives 3/5 because the supplied issue activity shows participation and follow-up, without establishing support responsiveness across the project. Maturity receives 3/5 because the repository run supports a trial, while application migration, integration behavior, and production workloads remain outside its scope.
Choose the workflow before choosing the framework
Go kit is relevant if you want packages with pluggable transport and serialization while retaining existing infrastructure choices. Its stated non-goals leave operational policy such as deployment and configuration outside the toolkit.
go-zero is relevant if you want to compare another web/RPC framework with specification-based generation. Its README describes goctl workflows using .api and .proto definitions. Neither alternative was tested in this run.
Start with one service whose HTTP and gRPC interfaces benefit from a shared contract. Use the current template, inspect its generated module and tooling versions, and verify a database-backed request. For an existing v2 application, budget for the migration guide's changes rather than treating the upgrade as only go get.