pprof

gin-contrib/pprof is a thin middleware that wires Go’s standard net/http/pprof handlers into a Gin application. Instead of standing up a second HTTP server just to expose profiling routes, you register this package on your existing Gin router (or a sub-group of it) and immediately get the full set of runtime profiling endpoints — heap, goroutine, block, mutex, threadcreate, CPU profile, command line, symbol lookup, and execution trace — available under a configurable path prefix.

Because registration happens on a gin.IRouter, the package composes naturally with Gin’s existing middleware and routing-group model: you can mount profiling behind an authentication middleware, under an admin-only route group, or with a custom prefix instead of the default /debug/pprof, all without touching the profiling handlers themselves. This makes it practical to leave profiling reachable in production behind a gate, rather than choosing between no profiling access and an unauthenticated one.

What You Get

• Register(router, prefix...) — one call to mount all standard pprof routes on a gin.IRouter, with an optional custom path prefix (defaults to /debug/pprof)
• RouteRegister(routerGroup, prefix...) — the same registration targeted at a specific route group, so profiling can sit behind an existing auth middleware chain
• Full coverage of the stdlib pprof surface: index, cmdline, profile (CPU), symbol, trace, allocs, block, goroutine, heap, mutex, and threadcreate handlers
• Compatibility with go tool pprof and pprof -http out of the box, since the routes wrap the same handlers those tools already expect
• Zero configuration required for the common case — a single pprof.Register(router) call is enough to get started

Common Use Cases

• Production debugging - ops or on-call engineers hit /debug/pprof/heap or /debug/pprof/goroutine on a running Gin service to diagnose a memory leak or goroutine buildup without redeploying
• Gated internal profiling - a team mounts pprof under an /admin group protected by an existing bearer-token or basic-auth middleware, so profiling is reachable only by authorized operators
• Load testing analysis - during a load test, an engineer captures a 30-second CPU profile via /debug/pprof/profile?seconds=30 to find hot paths before a release
• Local development - a developer registers pprof with the default prefix while iterating locally, using go tool pprof against the running dev server to catch performance regressions early

Under The Hood

Architecture The package is a single file, pprof.go, exposing two public functions — Register and RouteRegister — plus one unexported helper, getPrefix. Register is a thin wrapper around RouteRegister, which takes any gin.IRouter (a plain router or an existing route group), creates a sub-group at the resolved prefix, and attaches each of the eleven standard net/http/pprof handlers via gin.WrapF/gin.WrapH. There is no internal state, no config struct, and no abstraction layers beyond this adapter — the design deliberately defers all profiling logic to the Go standard library and limits its own surface to route wiring, which keeps the blast radius of a breaking change to essentially nothing.

Tech Stack Written in Go (module targets Go 1.25) with a single direct dependency, github.com/gin-gonic/gin v1.12.0; all profiling behavior comes from the standard library’s net/http/pprof package. The repo uses golangci-lint (via .golangci.yaml) for static analysis, GoReleaser (.goreleaser.yaml) for tagging releases, and GitHub Actions for CI, including a dedicated Trivy security-scan workflow and Codecov coverage reporting.

Code Quality pprof_test.go covers both the prefix-resolution helper with table-driven cases and an end-to-end integration test that registers routes on a plain router and on a route group guarded by a bearer-token check, asserting the expected 200/403 responses. Naming is short and direct, matching Gin’s own idioms, and there is no custom error handling to speak of since the package only wires existing stdlib handlers rather than implementing new logic. CI runs the test suite and linter on every change, giving reasonable confidence for a codebase of this size.

API Design The public API is deliberately minimal: a single Register(router, prefix...) call covers the default case, while RouteRegister exists specifically so profiling can be scoped to an already-protected route group. The optional variadic prefix argument avoids a second function signature for the common no-customization path, and because both functions accept the gin.IRouter interface rather than a concrete type, they compose with any existing Gin routing setup without special-casing.