Sprout
Sprout
Template for Go CLIs and daemons with signed, transactional updates.
All the hard parts done for you, wired up, and ready to go.
What you get
- Application structure. One
Appcontainer with shared initialization, cleanup, and error handling. - Shared state. Embedded SQLite in WAL mode gives each process durable state and a way to communicate, all without cgo.
- Optional features. Keep or cut the service, dashboard, or update behavior during setup.
- Daemon. A user systemd unit on Linux or scheduled task on Windows, with a binary-only install for systemd-less distros.
- CI/CD. Four build targets, signed artifacts, per-user installers, and resumable publication from a changelog entry.
- Dashboard. HTTPS, users, perms, and sessions. Tailwind, DaisyUI, and esbuild pinned / fetched by the build script. npm-free
Develop on Linux or WSL. Run on Linux, WSL, or native Windows 11.
amd64 and arm64. No macOS or BSD support. Platform details
Sprout and GoReleaser solve different problems
GoReleaser is mature release automation for Go apps that already exist. It builds, packages, signs, and publishes across many source hosts, registries, and packaging ecosystems. If you already have an app and just need release automation, I'd use it.
Sprout on the other hand is an app starting point and operating model. Its release flow is coupled to the app so an update can stop running processes, replace the binary, authorize and apply migrations, and restart safely. By coupling them and targeting Linux and Windows, you get extremely robust direct to user release and operation.
- Choose GoReleaser when you already have an application and want broad, established release automation, or need out of the box macOS support.
- Choose Sprout when you're starting a CLI / daemon and want to distribute direct to users on Linux and Windows, with the app, service, state, and release pipeline designed together for elevated robustness.
In theory you could combine them, but that'd mean recreating Sprout's pipeline across many package managers, and then you'd have N unique variants to maintain... With just Sprout, you have one universal transactional pipeline, only parts of it needing both a Windows and Linux implementation.