Flamingo is a Go framework built around modules and dependency injection

The module is the unit of composition, not the file

Flamingo describes itself as a web framework based on Go, designed to build pluggable and maintainable web projects, and the repository description says it is a Go based framework to build pluggable applications with a focus on clean architecture, maintainability and operation readiness.

The design decision that follows from that is the module concept. A Flamingo module is a self-contained unit with a Configure method that receives the dependency injector, and the application is assembled as a list of modules. The hello world walkthrough in the README shows it as plainly as it can be shown:

package main

import (
	"flamingo.me/dingo"
	"flamingo.me/flamingo/v3"
)

func main() {
	flamingo.App([]dingo.Module{
	})
}

So the application is a slice of modules passed to flamingo.App, and everything a module needs is injected into it rather than constructed inside it. That is the clean architecture claim made concrete, and it is the reason the framework exists rather than being a thin router wrapper.

The repository layout matches the same separation, with app.go at the root as the application entry point, core/, framework/ and examples/ directories, a docs/ tree, and a Makefile whose test target is three commands: go test with the race detector over everything, a gofmt check, and golint.

Dingo for injection, CUE for configuration, Cobra for commands

The feature list is a good map of the framework's scope, and three items carry most of the weight.

Dependency injection comes from Dingo, a separate project under the same organisation, and every module's Configure method takes a dingo.Injector. Configuration is handled with CUE, the configuration language from cuelang.org, with support for multiple config areas and additional config contexts, which is how a deployment inherits a base configuration and layers an environment on top of it.

Commands use Cobra, and the framework exposes itself as a command line tool rather than a bare server. Running the hello world project prints the available commands, and among them are config for a config dump, handler for dumping the handlers and their registered methods, routes for a routes dump, and serve as the default command which starts on port 3322. The routes and handler dumps are the interesting ones for a framework built around introspection: you can see what the application registered without reading the source.

The rest of the list covers templating with Go templates and pugtemplates, authentication concepts and security middleware, routing with prefix routes and reverse routing, a web controller concept with a request and response abstraction and form handling, event handling, session handling and management using Gorilla sessions by default, and localisation support.

Operation readiness gets its own entry: logging, distributed tracing, metrics and healthchecks with a separate endpoint.

Running the hello world project, and the port it lands on

The quick start is the one you would expect from a Go framework, and the README points at the examples/hello-world directory.

You initialise an empty project:

mkdir helloworld
cd helloworld
go mod init helloworld

Then you write the main file, which is the module list shown earlier, and running it prints the command list rather than starting a server. To actually serve, you use the serve sub command:

go run main.go serve

And the application answers on http://localhost:3322, which is the port the serve command uses by default.

The hello world extension is the part worth copying, because it shows the shape of a real module. A module type has a Configure method that calls web.BindRoutes with a routes type, the routes type implements a Routes method that registers a path and a name with registry.Route, and then registry.HandleAny binds that name to a handler. The handler itself takes a context and a web.Request and returns a web.Result, which in the example is a web.Response with a status and a body reader.

So the routing model is name based rather than path based, and the reverse routing support in the feature list is what makes that usable: you register a name once and refer to it from templates and redirects.

The last step is to add the new module to the module list in main.go, and the README states that running the server again and opening http://localhost:3322 shows the Hello World output.

The ecosystem around the framework

The README lists an ecosystem separately from the core feature list, and it explains what a framework like this is actually for.

There is a GraphQL module, and the README notes that this therefore supports building single page applications and progressive web apps on top of it. There are caching modules that provide resilience and caching for calls to external APIs. The pugtemplate engine does server side rendering, paired with related frontend tooling in Flamingo Carotene, which is a separate project for the build side of that arrangement.

And then there is Flamingo Commerce, described as an active project offering rich and flexible features for building modern e-commerce applications, which is the clearest signal about the kind of system this framework is aimed at. A commerce platform is a large, long-lived application with many teams, which is exactly the shape of problem that justifies a module concept and a dependency injector.

It is also the honest limit of the framework's appeal. If you are writing a service with four handlers and one template, none of this structure earns its keep, and the standard library plus a router would be less code than learning the module and injection model.

The Go dependency list reinforces the production framing. Alongside Dingo and CUE there is OpenCensus with Jaeger, Prometheus and Zipkin exporters, OpenTelemetry tracing, Redis with the go-redis client and a redisstore session backend, coreos go-oidc for OpenID Connect, golang-jwt, zap for logging, and the pact-go contract testing library. The module path is flamingo.me/flamingo/v3 and it declares Go 1.26.0.

Where Flamingo is the wrong choice, and the licensing position

Two limitations are worth stating before you adopt it.

The first is the learning cost of the conventions themselves. Dependency injection, CUE configuration and Cobra commands are three separate concepts to absorb before you write your first handler, and the module boundary is only useful if every team honours it. A framework that provides structure cannot also decide whether you should use it.

The second is the same point from the other direction. The framework's own claim is that it is production ready, field tested and has a growing ecosystem, and the evidence for that is the release history and the surrounding projects rather than a specification you can read. The v3 line has been stable across 3.17.2, 3.17.3 and 3.17.4, the last two of them in 2026, with the last push to master on 2026-10-16, so the tree is being worked on and the 3.x numbering has not broken in a way that would force a rewrite.

On licensing, the project is MIT, with the terms in the LICENSE file at the root, which is about as permissive as it gets for a framework you intend to build a product on. The repository also carries a SECURITY.md and a renovate.json for dependency updates, a CHANGELOG.md, and a Go Report Card badge alongside the usual CI and test badges.

The alternative approach, for comparison, is a plain Go service with net/http or a third-party router, a hand-rolled configuration file, and your own structure. The difference in approach is that Flamingo supplies conventions and an ecosystem where that alternative supplies none and leaves every decision to you, which is the right trade at one scale and the wrong one at another.

Editorial conclusion

Adopt Flamingo if you are building a Go web application that will carry several teams and needs a module boundary, dependency injection, layered configuration and operational endpoints from the first commit, since the framework supplies all of that as conventions rather than as libraries you wire together. Do not adopt it for a small service or an API where a router and a template engine would do, because the module and injection machinery costs more than it saves below a certain size. Before you commit, read the hello-world example and the docs at docs.flamingo.me, check that you are comfortable with CUE for configuration and Cobra for commands, and note the maintenance picture, with v3.17.4 published on 2026-07-13 and the last push on 2026-10-16.

Frequently asked questions

Official sources

1. i-love-flamingo/flamingo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases