Maestro: scaffold Go microservices and keep them in sync from a single file

The Go Project Ritual

Imagine you're building a brand new Go project. You fire up your code editor, create the folder structure, set up Taskfiles, create Dockerfiles even before you write any piece of meaningful Go code. You start piling up different microservices, different Dockerfiles and things can get messy quickly. This is why I built Maestro.

What is Maestro?

Maestro is a CLI for scaffolding Go microservices by creating a go.work workspace and the services underneath it by doing the labor work for you: per-service go.mod, Dockerfiles, dev/prod docker-compose, Air hot-reload, Taskfiles, secret wiring, and optional PostgreSQL/SQLite with sqlc + goose into one consistent layout you can task up immediately.

The part that drives my sanity when working with scalable Go projects

Many generators dump a pile of files once, then drift the moment you touch anything. Maestro treats project.toml as the source of truth

[project]
  name = "my-project"
  repo_owner = "yourname"

[service]
  [service.api]
    shape = "http"
    db    = "postgres"
  [service.worker]
    shape = "worker"

edit the file, run one command:

maestro refresh

...and every managed file updates to match while preserving your own edits. Add a worker, change a service's database, flip hot-reload is a config change plus one command, and the whole workspace stays coherent.

Every generated file is explicitly classified as managed or user-owned so refresh never clobbers the code you wrote.

Service shapes

Each service is generated in one of four shapes:

• bare - a minimal main.go
• http - Gin server with /health, ready, structured logging using zap, and graceful shutdown grpc - grpc.NewServer() with health + reflection and a buf-managed proto layout
• worker - a long-running loop over ctx.Done() with clean signal handling

Add a database and you also get sqlc.yaml, migrations, generated query code, and a local or a live database with a managed DATABASE_URL.

Presets: working features, not just skeletons

Presets scaffold a real feature and drop the libraries it's built from into common/go so you can build on top of those building blocks instead of being locked into generated code.

• auth-jwt - a JWT auth service providing email-OTP verify, password + Google sign-in, MFA, MFA-gated staff roles with RBAC, refresh rotation, and a clean up worker.
• api-gateway - a stateless edge: reverse proxy, edge JWT validation, signed gateway-to-service identity, Redis rate limiting.

Try it out today

go install github.com/Zagforge-Org/maestro@latest

mkdir my-project && cd my-project
maestro init
maestro service api
task up

Thanks for reading, feedback is welcome ❤️

Maestro is pre-1.0 and MIT licensed so things can and might break. I'd appreciate any feedback and which generated files you'd insist stay hand-owned versus managed.

Zagforge-Org / maestro

maestro

Maestro is a CLI tool that scaffolds scalable Go microservice projects. It follows an opinionated design pattern - go.work, per-service go.mod, Dockerfiles, docker-compose, hot reload, secrets, databases, and Taskfiles. Managing growing projects in Go can be tough, but with a single task up command you can get it up and running immediately.

Unlike a one-shot generator, maestro reconciles: project.toml is the source of truth, and maestro refresh brings every generated file back in line on demand - without clobbering your edits.

Built on top of the project.toml philosophy: one workspace, many services under it, each in its own module, all reconciled from a single project.toml

What it does

• Bootstraps a workspace with go.work, a shared common/go module with handy starter code, dev and prod compose files, Dockerfiles, Air hot-reload, .gitignore, and a root Taskfile.

• Generates services in four shapes (bare, http…

View on GitHub