Nunu: a Go scaffolding CLI that ships a Wire-injected layered layout
A CLI tool for building Go applications.
At a glance
- What is it?
- Nunu generates a Gin, Gorm and Wire project skeleton and then keeps writing into it. The value is the fixed directory contract; the cost is adopting a layout you did not design.
- Who is it for?
- Adopt Nunu if you want a Gin, Gorm and Wire project whose handler, service and repository boundaries are already drawn, and you are willing to let the CLI write files into that structure. Skip it if your architecture is event-driven, gRPC-first, or already has a layout you cannot move.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Nunu solves is directory agreement, not code generation
Every Go service starts with the same argument: where does the database call live, and who is allowed to call it. Nunu answers that by generating a fixed tree. The README describes it as a scaffolding tool whose name comes from a League of Legends character, and the layout it produces is the actual product. Under internal you get handler, middleware, model, repository, server and service. Under cmd you get migration, server and task, each with its own main.go. The README states that each cmd sub-module also carries wire.go and wire_gen.go for dependency injection. That is the whole pitch: the boundaries exist before the first feature does, so two engineers joining the same repository do not have to negotiate them. It is aimed at teams building HTTP services on Gin and Gorm who want a conventional shape and are content to inherit someone else's conventions rather than invent their own. It is not aimed at someone who already has a layout they like.
Wire does the wiring, so the directory tree is not just cosmetic
The interesting design decision is that Nunu does not hand you a main.go with everything constructed inline. It uses google/wire, and the README is explicit that the dependency injection framework is what makes the layering modular and decoupled. The practical consequence is that the generated wire.go declares providers and wire_gen.go holds the generated constructor graph. Adding a repository means adding a provider function and regenerating, not editing a growing chain of manual construction in main. This is a real constraint as well as a benefit. Wire resolves at build time through code generation, so the generated file is a build artifact you check in, and a provider that is declared but never used will surface as a compile-time complaint rather than a runtime nil. The README lists the rest of the stack as Gin, Gorm, Viper for configuration, Zap for logging, golang-jwt, go-redis, Testify, Sonyflake, Gocron, go-sqlmock, gomock, Swaggo, Casbin, Pitaya and mcp-go. Those are the libraries the generated project assumes. If you have already standardised on a different logger or a different ORM, Nunu is asking you to change that or to strip its choices out by hand.
Getting a project running: the nunu CLI and the commands the docs name
The README points to a user guide at docs/en/guide.md rather than inlining the full command set, so the exact flag list is something to read there before you start. What the repository does establish is the shape of the workflow. There is a nunu CLI, shown in a screenshot in the README, and its job is to create and extend projects against the layout above. The README also documents one adjacent install command for the agent skill: npx skills add go-nunu/nunu-skills --skill build-with-nunu. That installs an Agent Skill the README says helps coding agents such as Codex and Claude Code understand Nunu layouts and implement features across handlers, services, repositories, routers, Wire injection, jobs, tasks and MCP servers. Configuration lives in the config directory, which the README says provides different files for different environments such as development and production, read through Viper. Deployment scripts sit in deploy, and a Makefile at the repository root is the entry point for build, test and deploy operations, with scripts in scripts. The honest caveat: the README does not enumerate the CLI subcommands or their flags, so treat the guide and the CLI's own help output as the source of truth rather than any summary, including this one.
The layout is the limitation as much as the feature
Nunu generates an HTTP-first service. The handler layer receives requests, the service layer holds business logic, the repository layer talks to the database, and the README describes exactly that division. There is a task entry point under cmd and a job concept under internal, so background work has a home. But if your service is primarily a gRPC server, or if your domain logic does not decompose into request-response handlers, the generated structure is a frame you will fight. The same applies to the library choices. Casbin and Pitaya are listed among the features, which suggests the scaffold can pull in an authorisation engine and a game server framework, but a project that needs neither carries the conceptual weight of a layout designed to accommodate them. There is also a maintenance signal worth reading plainly. The README says the project is very complete and that updates will not be very frequent. Release dates support that: v1.1.6 landed on 2026-08-12, and before it v1.1.3 on 2025-08-11, roughly a year earlier. A scaffold that changes slowly is not automatically bad, because generated code is yours once written, but you should not expect the template to track upstream library releases promptly. Upgrading Gin or Gorm in a Nunu project is your task, not the maintainer's.
How it compares to a plain go mod init and a hand-built tree
The obvious alternative is starting from nothing: go mod init, add Gin and Gorm, and write your own directories. The difference is not speed of the first commit, it is what happens at month six. A hand-built tree encodes your team's decisions, and nobody has to read a README to know where a new repository goes. Nunu encodes the maintainer's decisions, and every new hire reads the same guide. The second alternative is a lighter generator such as a cookiecutter-style template with no CLI and no regeneration step. Nunu's distinguishing move is that it keeps operating on the project after creation, which is why the Wire files and the layered folders matter. The third comparison is to frameworks that invert control entirely, where you register handlers against a runtime rather than owning main.go. Nunu does not do that. The generated project is ordinary Go with ordinary imports, and you can delete the CLI from your machine the day after scaffolding and the code still builds. That is the strongest thing that can be said for it, and it is also why the CLI's ongoing usefulness depends on whether you keep adding modules in its idiom.
Maintenance, licence and what the MIT terms leave open
Nunu is MIT licensed. In practice that means the generated project carries whatever licence you choose, and the scaffold imposes no copyleft obligation on your service. This is not legal advice, and if your organisation has a policy on generated code provenance, the MIT text in the repository is short enough to read directly. On maintenance cost, the honest accounting is that a scaffold is a one-time cost plus a per-upgrade cost. The one-time cost is learning the layout and the Wire provider pattern. The per-upgrade cost is that Nunu's template lags its dependencies, so when Gin or Gorm ships a breaking change you are editing the generated code yourself. The repository also maintains sibling projects the README links to: nunu-layout-mcp for an MCP server layout and nunu-layout-monorepo for a monorepo layout. That matters if your organisation runs more than one service, because it means the layout is not a single fixed answer but a small family of them, and picking the wrong sibling early is a migration you would rather avoid. The README does not describe how those layouts diverge from the default, so read each repository before choosing.
Editorial conclusion
Adopt Nunu if you want a Gin, Gorm and Wire project whose handler, service and repository boundaries are already drawn, and you are willing to let the CLI write files into that structure. Skip it if your architecture is event-driven, gRPC-first, or already has a layout you cannot move. Before committing, run nunu new in a scratch directory, read the generated wire.go and wire_gen.go pair, and confirm the config keys under config match the environments you actually deploy to. The MIT licence places no conditions on how you ship the generated code.
Community notes