Kratos Go framework: cloud-native microservices
/kratos
Kratos is a Go framework that generates matching HTTP and gRPC server code from one Protobuf definition instead of hand-writing both. That protobuf-first workflow is the real payoff: define the API once, run `go generate`, and the stubs stay in sync. The v3 rewrite trims dependencies and makes implicit behavior explicit — worth adopting on a new service, not a casual upgrade if you're on v2.
What is Kratos
Kratos provides a lightweight Go framework designed for building cloud-native microservices. Rather than a monolithic toolkit, it breaks apart transport, middleware, service registry, config loading, logging, and wire encoding into individual, swappable pieces you opt into separately. It relies on Protobuf for API definitions and generating HTTP and gRPC boilerplate, employing the standard library's log/slog for logging rather than a custom logger. A separate contrib ecosystem provides optional integrations without expanding the core module's size.
Core capabilities of Kratos
- ✓API-first workflow: write a Protobuf definition once and generate matching HTTP and gRPC server and client code from it.
- ✓Unified transport layer that runs an HTTP server and a gRPC server side by side in the same service, as shown in the README's usage example.
- ✓Composable middleware chain covering recovery, logging, validation, tracing, metrics, and auth.
- ✓Pluggable registry, configuration, and encoding components you can swap without touching application code.
- ✓Logging built on Go's standard-library log/slog, with OpenTelemetry extensions available through contrib packages.
- ✓Consistent handling of metadata, errors, validation, and OpenAPI generation across services.
- ✓A separate contrib ecosystem for optional integrations — registries, config stores, middleware, encodings, observability — kept out of the core module.
When to use Kratos
- •Standing up a new Go microservice that needs to expose both an HTTP and a gRPC API from one codebase.
- •Teams standardizing on Protobuf as the single source of truth for API contracts across services.
- •Projects that want middleware like auth, tracing, and metrics applied consistently instead of wired ad hoc per handler.
- •Cloud-native deployments that need a pluggable service registry and config source rather than hardcoded values.
Installing Kratos CLI and prerequisites
Kratos requires Go 1.25 or later, plus `protoc` and `protoc-gen-go` installed, since the CLI generates code from Protobuf definitions. Install the CLI with `go install github.com/go-kratos/kratos/cmd/kratos/v3@latest`, then run `kratos upgrade`. From there, `kratos new helloworld` scaffolds a project; `cd helloworld && go mod tidy && kratos run` starts it, and the README says to visit `http://localhost:8000/helloworld/kratos` to confirm it's running.
Building a service with Kratos
For a fuller generated-service flow, the README's sequence is `kratos proto add api/helloworld/helloworld.proto`, `kratos proto client api/helloworld/helloworld.proto`, `kratos proto server api/helloworld/helloworld.proto -t internal/service`, then `go generate ./...` and `kratos run`. Wiring a service by hand looks like this: ```go package main import ( "github.com/go-kratos/kratos/v3" "github.com/go-kratos/kratos/v3/transport/grpc" "github.com/go-kratos/kratos/v3/transport/http" ) func main() { httpSrv := http.NewServer(http.Address(":8000")) grpcSrv := grpc.NewServer(grpc.Address(":9000")) app := kratos.New( kratos.Name("helloworld"), kratos.Version("v1.0.0"), kratos.Server(httpSrv, grpcSrv), ) if err := app.Run(); err != nil { panic(err) } } ``` Both servers register against the same `kratos.App`, so one `Run()` call starts and stops them together.
Strengths
- ✓One Protobuf definition generates both the HTTP and gRPC layers, so the two transports can't drift apart the way hand-written duplicate handlers do.
- ✓Middleware for recovery, logging, validation, tracing, metrics, and auth is composable rather than baked into one opinionated stack.
- ✓Registry, configuration, and encoding are pluggable, not locked to a single backend.
- ✓Logging rides on the standard library's log/slog instead of a bespoke logging API.
- ✓The contrib ecosystem keeps optional integrations out of the core module, so you only pull in what you use.
Limitations and v3 migration considerations
- △Moving from v2 to v3 isn't a drop-in swap — the README says v3 reduces core dependencies and makes previously implicit behavior explicit, and points to a dedicated migration guide you're expected to read first.
- △Generating anything beyond the starter example depends on protoc and protoc-gen-go being installed and on your PATH, an extra toolchain step most single-binary Go projects don't need.
- △The README doesn't document a full v3 API reference inline; you're routed to the external docs site and the migration guide for anything past the hello-world example.
- △WeChat is listed alongside Discord as a community channel, which signals the core contributor base and support channels lean toward a Chinese-speaking audience.
How Kratos compares to other Go frameworks
Frequently asked questions
Kratos is free and open source software, licensed under MIT. The go-kratos/kratos GitHub repository holds the full source code, and MIT terms permit commercial use, modification, and redistribution without a paid license.
Kratos requires Go 1.25 or later, per the project's installation requirements. You'll also need protoc and protoc-gen-go installed alongside that Go version, since Kratos's CLI generates HTTP and gRPC code from Protobuf definitions.
Kratos supports both gRPC and HTTP through its unified transport layer, with dedicated transport/http and transport/grpc packages. Its own usage example runs an HTTP server and a gRPC server side by side in one application, wired together with kratos.Server(httpSrv, grpcSrv).
Kratos v3 reduces the framework's core dependencies and turns behavior that was previously implicit in v2 into explicit configuration, per the project's migration notes. The README advises reviewing the dedicated v2-to-v3 migration guide before upgrading any production service.
Kratos is licensed under the MIT license, as stated in the project's LICENSE file and README. MIT is a permissive license, so you can use, modify, and redistribute Kratos in commercial projects without releasing your own source.
Kratos is designed for production cloud-native services — its middleware set covers recovery, tracing, metrics, and auth, the pieces production traffic needs. The README does specifically warn to review the v2-to-v3 migration guide before upgrading an existing production service to v3.
The problem it solves
Building a Go microservice that speaks both gRPC (for internal calls) and HTTP (for external clients or webhooks) usually means maintaining two separate API definitions that drift apart as the service grows. Kratos makes Protobuf the single source of truth: define the API once, then generate both the HTTP and gRPC server code from it, plus client stubs, instead of hand-rolling parallel handlers for each transport.
Who should try it — and who should skip
Go teams building more than one microservice that need HTTP and gRPC to share a single API definition are the clear fit for Kratos — the code-generation workflow pays for itself once you're keeping a few services in sync. A solo developer shipping one HTTP-only API doesn't need Kratos's registry, middleware chain, and protobuf toolchain. Skip it. gin or plain net/http gets there with far less setup. Anyone still running Kratos v2 in production should budget time for the migration guide before touching v3.
Related repositories
Is kratos worth your time?
ChatGPT, Claude and Perplexity can all read this page. Ask one of them what it makes of kratos.