Prod Forge (backend)
“AI made writing the code easy. Running it in production is still hard.” That line opens the README, and it is this spoke’s premise stated by someone who then wrote down all sixteen chapters of the answer.
Prod Forge is a three-repository reference implementation — backend (NestJS, “the main guide”), frontend (React), infrastructure (Terraform on AWS) — built around a Todo API and documented decision by decision. MIT, TypeScript, 217 stars / 12 forks at ingest. T1 as an official project repo, and unmeasured: nothing here is backed by an incident, a load test or a number.
What it covers
Sixteen chapters, and the span is the point: repository strategy · architecture decisions · development workflow (git flow, commit conventions, squash-merge, review) · AI-assisted development · six layers of code quality · documentation (including an incident log) · configuration and secrets · database migrations · project structure · fault tolerance · error handling · logging and observability · testing · performance · security · release management.
The stack is the small-team default rather than anything exotic: NestJS, Prisma, PostgreSQL, Redis, Docker; AWS ECS/RDS/ElastiCache/S3/CloudFront behind Terraform; prometheus, Grafana, Loki and Promtail for observability; Sentry for errors; ESLint, Prettier, Husky and Commitlint on the way in.
Some of the decisions are specific enough to argue with, which is what makes it useful:
- Fault vs failure, with dependencies split into critical and non-critical, and fallbacks
(cache, throttle) defined per class. Health endpoints follow the same split —
/healthcovers critical dependencies and readiness,/health/depsreports everything — so an optional dependency being down cannot take the service out of rotation. - Graceful degradation and in-flight request handling as named concerns rather than as a shutdown afterthought.
- Migrations run inside the deployment pipeline, with revision cleanup after deploy and rollback against tracked revisions.
- Trace ID threaded through logs, errors and Sentry context, plus GDPR constraints on what may be logged at all.
Where it sits in this spoke
Every other source here operates at a scale that justifies its own platform team: netflix-service-topology fuses three telemetry streams across thousands of services, zalando-cslb-1m-rps rebuilds load balancing at a million requests a second, modal-1m-sandboxes schedules a million sandboxes, google-sre-book writes from Google. This is the opposite end of the same discipline — one small service, one team, and the same checklist (production-readiness).
That makes it a useful control on the spoke’s central claim. The thesis here is that the hard problem is the seams, not the components, and Prod Forge is what the seams look like when there are only a few of them: no service mesh, no kubernetes (ECS, with a Kubernetes variant on the roadmap), no service-topology to assemble, and yet the same list of concerns survives — health semantics, dependency classification, telemetry correlation, migration ordering, rollback. The kubernetes-integration-tax argument says the tax is paid on making ~20–30 CNCF tools cohere; this repo suggests a floor underneath that, paid by anyone shipping anything.
The AI chapter, which belongs to another spoke and is worth naming
Chapter 4 is a complete agent-governance configuration, in agentic-tooling-wiki’s vocabulary and partly in
Claude Code’s actual syntax: quality gates established before generation, architecture before
generation, plan-then-implement, saved prompts, project knowledge files (MEMORY.md, REVIEW.md, docs/,
Skills), and pre-hooks enforcing protected files (Edit|Write) and blocked commands (Bash), under
headings that include Mandatory Code Review and Never Trust AI Blindly.
Read against that spoke’s standing constitution-vs-containment argument, this lands on the containment side and does it with hooks rather than prose — the same shape as its guardrails thread, arriving from a production-engineering repo that is not selling an agent product. Cross-linked, not duplicated: the agent machinery is agentic-tooling’s subject, and the reason it appears in a production checklist is this spoke’s.
What it cannot establish
A Todo API. No traffic, no incident history, no postmortem, no benchmark, no failure the design is shown to have survived. The decisions are a curated opinion, coherent and conventional, and the repository’s own framing is that you clone the patterns rather than the code. So it documents the floor of production-readiness without evidence about which parts of that floor actually load-bear — which is the same evidential hole the spoke’s own dora-metrics/service-level-objectives question keeps running into, in a source that could plausibly have closed it and did not.
Related
production-readiness · platform-ops · observability · prometheus · site-reliability-engineering · kubernetes-integration-tax · internal-developer-platform · dora-metrics · service-level-objectives · gitops · agent-guardrails · claude-md