What GoFr is
GoFr is an opinionated Go framework for building microservices. It bundles HTTP routing with REST defaults, gRPC, configuration, logging, tracing, metrics, database migration, Pub/Sub, cron jobs, Swagger rendering, websockets, and health checks in one import. The project is listed in the CNCF Landscape and targets Kubernetes deployments. The primary language is English; the README and docs site are in English.
What happened when we ran it
We cloned gofr-dev/gofr at commit 2d78c40 on 2026-09-09 and ran it in a fresh Debian container with Go 1.24, 3 CPUs, and 8 GB RAM. Installation succeeded in 108 seconds and pulled 594 packages. Building a clean binary succeeded in 112 seconds. The test suite did not pass: go test exited with code 1 after 160 seconds, reporting 95 passed and 12 failed out of 107 total tests. The final failing package is gofr.dev/pkg/gofr/metrics/exporters, with two failing tests: TestBuildResource_carriesRequiredLabelSources and TestBuildResource_schemaURLConflictIsNotAFailure. The log shows the package reached those tests and failed, not a timeout or missing dependency. So a sample app is likely easy to start, but the repository's own test suite is red on a standard Go image.
Version, release cadence, and rough edges
The latest release is v1.60.1, tagged on 2026-09-02, seven days before our run. The last push is on 2026-09-09, the same day. That signals active maintenance at first glance. However, a framework whose headline is out-of-the-box observability has failing tests in its metrics exporter package, which is a rough edge. Our install fetched 594 packages, a substantial dependency surface for a small service. The README requires Go 1.24 or above, so teams pinned to older toolchains cannot use this release. In our run, the build succeeded, so the public API compiles; the failures are limited to tests, but they are still the project's own tests, not third-party flakes.
Strengths from the README
The main strength is consolidation. The example app is just gofr.New(), a GET handler, and Run(). The README lists 15 built-in features that would otherwise require separate libraries: auth middleware and custom middleware, HTTP with circuit breaker support, Pub/Sub, cron, health checks for all datasources, database migrations, remote log level changes without restart, Swagger, abstracted filesystems, and websockets. For a new service that needs HTTP plus gRPC plus scheduled jobs, GoFr can replace a few days of library evaluation with one import. Apache-2.0 licensing and the gofr.dev docs site lower the barrier further. The project has 20,939 stars and a Discord for help.
Where GoFr is not the best fit
If you only need a fast HTTP router with middleware, GoFr carries more machinery than necessary. In our run, installing the module required 594 packages and 108 seconds; a lightweight router would be far quicker. The failing test suite makes it less attractive for contributors who want a green go test ./... before coding. The opaque failure in metrics/exporters may be a genuine bug or an environment assumption not documented in the README; either way, it is friction. For teams that already have chosen Echo, Prometheus, and NATS, GoFr's opinionated defaults may conflict with existing choices.
Community and maintenance
Repository activity looks live: last push 2026-09-09, latest release v1.60.1 on 2026-09-02, and 134 open issues. The project was created on 2023-10-24 and has reached version 1.60 in under three years, which is a fast feature cadence. Four CI workflow files and a Dockerfile are present. There is no separate tests directory, but that is normal in Go; tests live next to packages. The failing tests on our run raise the question of whether CI is configured to catch the same failures; the data does not show CI status, so we can only report our local result.
It fits behind an existing gateway, not in front of one
GoFr works as the backend service layer behind an API gateway or ingress controller in Kubernetes. Use it for new internal microservices where you want HTTP and gRPC, cron, health checks, and telemetry wired by default. It is not a replacement for Envoy, NGINX, a service mesh, or a frontend framework. For a small public API that only needs routing and middleware, Gin or chi is simpler and lighter. For teams that want a full microservice toolkit with less code, GoFr is a legitimate option, provided you can tolerate the test suite being red and the dependency weight.