go-tool-base

The underpinnings for any Go application that ships as a binary: command-line tools to start with, and (as more than half of what is built on it now proves) long-running services and local web UIs too. It standardises the boilerplate and wiring you end up writing in every Go project, and puts config, logging, self-update, a DI container and the rest straight at your fingertips. Highly opinionated, and it makes some calls people will disagree with, but it works, and it works really well. The CLI it ships with is a big part of that: keeping a Go app built, updated and maintained becomes almost trivial.

Stand up a production signing key in AWS KMS with Terraform, so the private half is generated inside KMS and can never be exported.

A generated nested command would not compile, and the cause was a scaffolder handing every call the same key regardless of depth.

The laptop-only quick start: make a signing key, mint the public key you publish, sign a file, and verify it with both gtb and plain gpg.

Whoever controls your release page can swap a binary, and a checksum hosted beside it proves nothing. A seven-part guide to signing releases.

Building an AI dungeon master to test a Go chat client, and the bug that kept resurrecting a goblin the player had definitively killed.

Generate an asymmetric RSA-4096 signing key inside AWS KMS with no export path, then sign releases by calling kms:Sign instead of holding the key.

Generating a Go command from a shell script or a plain sentence, and the repair agent that has to make the result build before you see it.

A checksum proves the bytes match the manifest, but says nothing about who wrote the manifest. Why self-update needs a signature instead.

Operational telemetry can be personal data, and a web service has no first-run prompt to ask on. So plumbing is not an answer.

Two telemetries with opposite consent defaults on one OTLP layer: consent-gated analytics for a CLI, implied-consent observability for a service.