Go project setup
A standardized setup for Go projects with telemetry and CI/CD built in, so a new service goes from local test to production in minutes.
Local test to production in minutes
01
Why I built it
- Every new Go service meant rebuilding the same setup: telemetry, CI/CD, infrastructure and auth.
- Services built that way drift apart, and fixes in one never reach the others.
- The idea: one template, so a new service starts production-ready and stays in line with the rest.
- Go
02
What it does
- One command bootstraps a new service end to end.
- A Claude Code skill runs the template, sets up GitHub secrets and environments, and opens the PRs that register the repo and the load balancer.
- Template changes reach every existing service: another skill opens a pull request in each one, keeping its own customisations.
- GitHub
03
How it’s built
- The OpenAPI spec is the contract: server code is generated from it and every request is validated against it.
- The running service is fuzz-tested against the spec before each push.
- Telemetry from the first commit: OpenTelemetry traces, logs linked to their traces, and an error alert for every service.
- One pipeline from pull request to production: lint, tests and vulnerability checks, a Terraform plan on every PR, then stage and prod on merge.
- Secure defaults: internal-only ingress, service-account auth, secrets that never show up in logs, and non-root containers.
- Terraform
04
Outcome
- A new service goes from local test to production in minutes.
- Every service is observable, tested and deployed the same way.