Snippets
Copy-paste, not copy-adapt
Real, working templates — a Dockerfile, a compose stack, a Kubernetes manifest — each correct on its own. The seed of a full container-recipe repository; more arrive over time.
20 of 20 snippets
Node.js app
A single-stage Dockerfile for an Express/Node HTTP service.
Node.js app (multi-stage)
Builds a TypeScript/bundled app in one stage, ships only the output in another.
Python app
A Dockerfile for a Flask/FastAPI-style Python service.
Go app (multi-stage, distroless)
Compiles a static Go binary, then ships it on a distroless base with no shell or package manager.
Static site (build + nginx)
Builds a frontend (Vite/React/etc.) and serves the static output with nginx.
.dockerignore
A sensible default .dockerignore for most app images.
Web + Postgres + Redis
The standard three-service local stack: an app, a database, and a cache.
WordPress + MySQL
A classic WordPress site backed by MySQL, with persistent volumes.
Local dev override
A docker-compose.override.yml that bind-mounts source and enables hot reload, merged automatically over the base file.
Deployment + Service
The standard pair for a stateless web app: a Deployment to run it, a Service to reach it.
Ingress with TLS
Host-based HTTPS routing into two backend Services.
ConfigMap + Secret in a Pod
Injecting non-secret config and a sensitive value into the same container.
StatefulSet for Postgres
A single-node Postgres StatefulSet with a persistent volume claim template.
CronJob
Runs a container on a cron schedule, with retry and history limits.
Helm _helpers.tpl
The standard named-template helpers almost every chart ends up needing for consistent names and labels.
Helm chart dependency
Pulling in a public chart (Postgres, here) as a dependency of your own, toggled by a values.yaml flag.
Helm post-upgrade hook (migration Job)
A Job that runs automatically after every helm upgrade -- the standard shape for a database migration step.
GitHub Actions: build, scan, push
Builds a container image, scans it for vulnerabilities, and pushes it to GHCR on every push to main.
GitHub Actions: build & test (no push)
Builds the image and runs the test suite inside it on every pull request -- no registry, no secrets.
GitLab CI: build, scan, push
Builds a container image, pushes it to GitLab's own registry, and scans it with GitLab's built-in Container Scanning.