Most Go web frameworks give you a library and send you on your way. Fiber ships a CLI tool that handles the repetitive tasks around development: live reload when files change, project scaffolding from templates, serving static files with one command, and migrating between Fiber versions automatically.

You do not need the CLI to use Fiber. But once you try fiber dev instead of manually restarting your server after every change, you will not go back.

Documentation tells you what an API does. Blog posts explain the why. But when you need to build something real - authentication with JWT, deployment to AWS, a WebSocket chat, a CRUD app with Postgres - what you really want is working code you can copy and adapt.

That is what the Fiber Recipes repository is. Over 70 complete, runnable example projects covering everything from "Hello World" to clean architecture with Docker, OAuth2, and Kubernetes. Every recipe is a self-contained Go project with its own go.mod, main.go, and README.

Fiber's core ships with 20+ middleware - logger, CORS, rate limiter, sessions, and more. But some middleware needs external dependencies: JWT requires a token library, OpenTelemetry needs the OTel SDK, WebSockets depend on a WebSocket implementation. Instead of bloating Fiber's core with these dependencies, they live in a separate repository: gofiber/contrib.

The contrib packages are first-party middleware. Same team, same quality, same release cycle. The only difference is that they have external Go dependencies, so they are imported separately to keep your go.sum clean when you do not need them.