go-blueprint: a CLI that scaffolds Go HTTP projects around your chosen framework

What go-blueprint generates, and who the CLI is aimed at

The README describes go-blueprint as a CLI tool that spins up a Go project with a corresponding structure, and that optionally integrates one of several popular Go frameworks. The problem it addresses is the first hour of a new Go service: picking a router, laying out cmd and internal directories, wiring a database driver, and repeating that work every time. The README frames the payoff as focusing on the actual code of your application rather than the scaffolding around it.

The audience is narrow but real. It suits someone starting a Go HTTP service who has not settled on a house layout, or a developer who wants to compare how the same small application looks under Gin, Chi, Fiber or Echo without writing four skeletons by hand. It is a generator, not a library. Nothing in the repository layout suggests it ships runtime code into your binary; the dependencies in go.mod (Bubble Tea, Lip Gloss, Cobra, pflag) are the CLI's own terminal UI and command parsing, not anything your generated project imports.

If you already maintain an internal template repository, go-blueprint competes with it rather than complementing it. If your project is not an HTTP server with a router at its centre, the framework choice that drives the whole generator is irrelevant to you.

Frameworks and database drivers the create command can wire

The README lists six supported frameworks: Chi, Gin, Fiber, HttpRouter, Gorilla/mux and Echo. Fiber is the odd one out, since it is built on Fasthttp rather than net/http, and the README notes that distinction directly when it says the tool sets up a Go HTTP server or Fasthttp with Fiber. That matters if you rely on net/http middleware or handlers, because Fiber's interfaces are its own.

Database support is selected at generation time with the --driver or -d flag. The README lists MySQL, Postgres, SQLite, Mongo, Redis and ScyllaDB GoCQL. Note that these are different kinds of store bundled under one flag. Postgres, MySQL and SQLite are relational and use database/sql-shaped drivers; Mongo is a document store; Redis is a key-value cache. The generator will place the driver you pick, but the README does not describe a repository or migration layer on top of it, so the wiring you get is the driver, not an opinionated data access pattern. Treat the driver flag as a starting import, not as an architecture decision the tool has made for you.

Advanced features and the coupling between Tailwind and HTMX

The --advanced flag turns a single-choice generator into a multi-select prompt. The README states that one or more features can be selected at the same time, and lists HTMX with Templ, a GitHub Actions CI/CD workflow, a WebSocket endpoint, Tailwind CSS, a Docker configuration, and a React frontend in TypeScript with an example fetch request to the backend.

There is one documented coupling worth reading twice: selecting Tailwind automatically selects HTMX unless React is explicitly selected. That is a sensible default, since Tailwind without a templating layer is less useful in a server-rendered Go app, but it is a side effect rather than a question, and it means a command that asks for Tailwind and nothing else produces more than you asked for. The README also notes that features can be enabled individually with --feature alongside --advanced, which is the more predictable path if you want to know exactly what lands in the tree.

The README does not document how these features interact after generation. If you select both React and HTMX, for example, it does not say how the two front ends coexist in the generated layout. Generate one combination at a time and inspect the output before adding a second feature.

Installing go-blueprint and running a first create

Three install paths are documented. The Go install compiles the CLI from source and places the binary in your GOPATH bin directory. The README warns that Zsh users may need to add that directory to PATH manually.

go install github.com/melkeydev/go-blueprint@latest

If you use Zsh and the command is not found afterwards, the README gives this line for ~/.zshrc, followed by sourcing the file again:

GOPATH=$HOME/go  PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

The other two paths are a global npm package and a Homebrew formula, for readers who would rather not build from source.

npm install -g @melkeydev/go-blueprint

brew install go-blueprint

With the binary on PATH, running go-blueprint create with no flags opens the interactive prompt. For a non-interactive run, the README gives this example, which names the project, picks Gin, selects the Postgres driver and asks the tool to commit:

go-blueprint create --name my-project --framework gin --driver postgres --git commit

The README points to go-blueprint create -h for the full option list and shorthands, so check that output rather than assuming a flag exists. For the advanced path, the README shows a single command that enables every feature at once, which is a useful way to see the whole surface in one generated tree:

go-blueprint create --name my-project --framework chi --driver mysql --advanced --feature htmx --feature githubaction --feature websocket --feature tailwind --feature docker --git commit --feature react

There is also a hosted web application, Blueprint UI, at go-blueprint.dev. The README says it lets you build the command and preview the directories and files that would be created before you execute anything. That preview is the cheapest way to check whether a combination produces a layout you want.

Where go-blueprint is the wrong tool

The generator's output is a snapshot. Once the files exist in your repository, go-blueprint has no further role: the README does not document an upgrade command, a sync command, or any mechanism for pulling later template changes into an existing project. If the project's templates improve, or a framework's recommended layout changes, you re-generate and diff by hand. That is normal for scaffolding tools, but it should be stated plainly, because it means the cost of adoption is front-loaded and the cost of staying current is manual.

The second limitation is the framework list itself. Six routers is a curated set, not a survey, and the advanced features are similarly opinionated: Templ for HTMX, TypeScript React for the front end, GitHub Actions for CI. If your team uses GitLab CI, or Vue, or a different templating engine, the generated files are something you delete rather than something you configure. The README describes the project as focused on being as minimalistic as possible, which is consistent with that: it offers a set of choices, not a plugin system.

Finally, the tool assumes an HTTP service. If you are writing a CLI, a worker consuming a queue, or a library, the framework selection that structures the whole generated tree is dead weight.

How go-blueprint compares with copying a template repository

The obvious alternative is a template repository plus a copy step. That approach gives you exactly one layout, maintained by your own team, with your own conventions baked in. go-blueprint's difference is combinatorial: the same command surface spans six routers, six database drivers and six optional features, and the README's own example chains them into one invocation. You get variety without maintaining six branches.

The trade-off runs the other way too. A template repository is a single artifact you can review once and trust; go-blueprint is a generator whose output depends on the flags you passed, so two projects created a month apart may differ. The Blueprint UI preview mitigates this by showing the tree before execution, but it is a preview, not a lockfile.

A second alternative is simply writing the skeleton yourself. For a Gin service with one handler and a Postgres connection, the boilerplate is small enough that a generator may not pay for itself. go-blueprint earns its place when you are genuinely undecided between frameworks, or when you want the Docker, CI and front-end pieces generated together rather than assembled from four separate sources.

Maintenance, releases and the MIT licence

The repository is not archived, and the last push was on 2026-04-26. The most recent release listed is v0.10.11 from 2025-07-10, with v0.10.10 and v0.10.9 before it in May 2025. The version numbering has stayed in the 0.10.x line, which is consistent with a tool that adds frameworks and features incrementally rather than one that has declared a stable interface.

That matters for adoption in a specific way: a 0.x CLI can change its flags between releases, and the README already points readers to go-blueprint create -h rather than documenting every option inline. Pin the version you install if you script project creation in CI, and read the release notes before bumping.

The project is licensed under MIT, per the README and the LICENSE file at the repository root. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. It says nothing about the licences of the frameworks and drivers you select during generation, and those are separate dependencies with their own terms. That is a question for your own dependency review, not something the go-blueprint licence settles.

Editorial conclusion

Adopt go-blueprint if you want a Go HTTP skeleton with a framework and a database driver already wired, and you are willing to read the generated code before building on it. Skip it if you already have an internal project template, or if your service is not an HTTP server with a router at its centre. Before committing, run go-blueprint create -h to see the current flag set, generate one project with the framework and driver you actually intend to use, and check the generated go.mod for the dependency versions you will inherit.

Frequently asked questions

Official sources

1. License: MIT
2. Melkeydev/go-blueprint on GitHub
3. Project website
4. README
5. Releases