Go API Project Checklist to Run Through Before You Launch

A launch is the moment an API stops being yours and becomes someone else's problem to depend on. The checks below are what I would want answered before that moment. They are written as questions with yes or no answers, grouped by area, with a link to the longer article for each. Print it, paste it into a pull request template, or turn the automatable half into CI jobs. A team that has run through the list once usually finds three things in half an hour.

Contract

• Is every endpoint described in an OpenAPI document or an equivalent, reviewed like code? (shared contracts)
• Are status codes, error shape and pagination consistent across endpoints? (status codes, problem details)
• Is there a versioning approach in the URL or a header, and a written deprecation policy? (versioning, deprecation)
• Do documented examples run? Are they tested?
• Do clients know what changes count as compatible? (compatibility)

Configuration

• Does all configuration come from environment variables or a config file, with no secrets in the repository or the image?
• Does the service fail fast at start-up on missing or invalid configuration, with a message that names the setting?
• Is the same binary used in every environment?
• Are timeouts, pool sizes and limits configurable without a rebuild?

Data

• Are schema changes versioned migrations that run once, in order, in CI and in production? (choosing a migration tool)
• Are migrations backward compatible with the previous release, so a rolling deploy works?
• Are database connections bounded (SetMaxOpenConns or pool MaxConns), and does the total across instances fit under the database's limit?
• Is there a tested backup and restore, with a stated recovery time?
• Are unique constraints, foreign keys and CHECKs in the schema, and not only in handlers?
• Is deletion behaviour decided: soft delete, hard delete, retention? (soft deletes and audit trails)

Limits

• Is every request body size-limited and every JSON structure depth and count limited? (input limits)
• Does the http.Server set ReadHeaderTimeout, IdleTimeout and sensible read and write timeouts? (server timeouts)
• Does every outgoing call have a timeout, and does every handler pass the request context down? (timeouts and retries)
• Are there rate limits per client, and a documented response when exceeded? (rate limiting)
• Are list endpoints paginated with a maximum page size? (pagination)
• Has the API been load tested at twice the expected peak, with a result recorded? (load testing)

Security

• Does every route have an explicit authentication and authorisation decision, verified by a test that walks the router?
• Is every object lookup scoped to the caller? (BOLA and IDOR)
• Do request types list only editable fields, with unknown fields rejected? (mass assignment)
• Is outgoing fetching of user-supplied URLs restricted? (SSRF)
• Are CORS origins an allow-list, TLS enforced and security headers set? (security checklist)
• Does govulncheck run in CI, and are dependencies pinned and reviewed?
• Are secrets rotatable without a deploy?

Observability

• Does every request get an id that appears in logs, traces and error responses? (request IDs)
• Do logs avoid tokens, passwords and personal data? (logging without leaking secrets)
• Are request count, error rate and latency exported per route template?
• Are traces propagated across services? (tracing)
• Is there an SLO with an alert on burn rate, not only on raw error percentage? (SLOs)
• Do health endpoints distinguish liveness from readiness? (health checks)

Deployment

• Does the process shut down gracefully on SIGTERM, finishing in-flight requests within a deadline? (graceful shutdown)
• Does the container run as a non-root user, built with CGO_ENABLED=0 where possible and a small base image?
• Is there a rolling or blue-green deployment, and has a rollback been rehearsed?
• Does GOMAXPROCS match the container's CPU limit? (GOMAXPROCS in containers)
• Are at least two instances running in different failure domains?

The first week

• Is someone on call, with a runbook for the five most likely failures?
• Is there a dashboard that shows the SLI, traffic and errors on one screen?
• Are client developers told where to ask questions and where to see status?
• Is there a plan to review the logs and error budget after seven days?
• Do you know how to turn off a misbehaving endpoint or client without a deploy? (a feature flag or a blocklist, feature flags)

Automating the list

The items that have a mechanical answer should not depend on someone remembering. A CI pipeline for a Go API usually runs gofmt -l, go vet ./..., staticcheck, go test -race ./..., govulncheck ./..., an OpenAPI lint and breaking-change check, and the integration tests against a real database. Add a router-walking test for access policies and a check that migrations apply to an empty database and to a copy of the previous schema. Keep the remaining questions in the pull request template for the launch review.

The Go project publishes its own guidance on security best practices, and the Google SRE book's launch coordination checklist is the long-form ancestor of lists like this one.