DEVELOPER RESOURCES

Dockerfile & Compose Starter Pack

8 production-grade Dockerfiles and 5 ready-to-run Compose stacks. Every Dockerfile is multi-stage, non-root, healthchecked, cache-ordered and pinned — hadolint-clean and actually built, with measured image sizes (Go: 16.0 MB, Rust: 37.9 MB, static+nginx: 72.2 MB). Node/TS, Next.js standalone, FastAPI, Django, PHP-FPM+nginx, Go, Rust, static. Each ships a sample app so `docker build .` works before you change anything.

  • Instant download Secure link seconds after payment
  • Commercial license Unlimited paid client projects
  • 14-day refund If it doesn't work as described

What's inside

  • 8 production Dockerfiles: Node/TypeScript, Next.js standalone, Python/FastAPI, Python/Django, PHP-FPM + nginx, Go, Rust, static site + nginx
  • 5 ready-to-run Compose stacks: app+Postgres, app+Postgres+Redis, local dev with hot reload, Caddy reverse proxy with automatic TLS, Postgres backup sidecar
  • Every Dockerfile multi-stage, non-root (numeric uid), HEALTHCHECK'd, cache-ordered, base-image pinned, with a matching .dockerignore
  • A header comment in every Dockerfile: what it builds, its build args, and the measured final image size
5 more included — see the full list →

About this product

Most Dockerfiles in production were copied from a blog post in 2019. They build as root, install dev dependencies into the shipped image, invalidate their own cache on every commit, and have no HEALTHCHECK, so nothing above them knows whether the app inside is actually alive.

This pack is 8 Dockerfiles and 5 Compose stacks that get those details right, with the reasoning written down beside each decision. Every file was linted with hadolint and actually built — the image sizes below were measured with docker images, not estimated.

The 8 Dockerfiles

  • Node + TypeScript — 224 MB, uid 1000. Four stages, with a separate clean npm ci --omit=dev instead of npm prune.
  • Next.js standalone — 311 MB, uid 1001. output: "standalone", and the two extra COPY lines everyone forgets that stop every stylesheet 404-ing.
  • Python + FastAPI — 276 MB, uid 10001. Hash-locked requirements, separate liveness and readiness probes that do different things on purpose.
  • Python + Django — 272 MB, uid 10001. collectstatic in its own stage, WhiteNoise, a real gunicorn config file, and an access log that filters the healthcheck.
  • PHP-FPM + nginx — 196 MB, uid 82. Extensions compiled in a throwaway stage, opcache tuned for immutable images, and nginx configured so only index.php is ever executable.
  • Go16.0 MB, uid 65532. Static binary on distroless: no shell, no package manager, nothing to pivot with.
  • Rust — 37.9 MB, uid 65532. The stub-build trick that stops every source edit recompiling your entire dependency tree.
  • Static site + nginx — 72.2 MB, uid 101. Assets compressed once at build time and served with gzip_static, read-only document root.

The 5 Compose stacks

  • app + Postgres — healthcheck-gated startup (condition: service_healthy), named volume, credentials from an env file, ports bound to loopback.
  • app + Postgres + Redis — Redis with requirepass, AOF persistence and an eviction policy you choose deliberately.
  • Local dev with hot reload — builds the builder stage of the same production Dockerfile, bind-mounted source, seeded Postgres, Adminer.
  • Caddy reverse proxy + automatic TLS — Let's Encrypt certificates issued and renewed with no certbot and no cron, plus security headers and active upstream health checks.
  • Postgres backup sidecarpg_dump on an interval, atomic writes, retention pruning, its own staleness healthcheck, and a restore procedure that has been run.

Every Dockerfile, without exception

  • Multi-stage, so compilers and dev dependencies never reach the shipped image
  • Runs as a non-root user, declared as a numeric uid so runAsNonRoot enforcement can verify it
  • Layers ordered so dependency installs actually cache
  • A HEALTHCHECK that probes the real app — including on the two distroless images, where the binary probes itself because there is no shell
  • An explicitly tagged base image; no :latest in any final stage
  • A .dockerignore beside it
  • A header comment: what it builds, its build args, and the measured image size

It builds before you change anything

Each stack ships a small sample app — a TypeScript service, a Next.js page, FastAPI with real readiness checks, a Django project, a PHP front controller, a chi service, an axum service, a static site. Unzip, cd, docker build ., and you have a running healthy container. Then delete the sample and point the Dockerfile at your code; each README lists exactly what it assumes about your app.

What it is not

Not a boilerplate app, not a framework, not a course. 94 files you copy into projects you already have. If you already know why npm prune --production is worse than a second npm ci, you have written these yourself and do not need this.

Why $29

Getting one of these right from scratch — multi-stage, non-root, caching correctly, healthchecked, and actually tested — is most of an afternoon. There are eight of them here, plus five Compose stacks, all verified.

What's included

  • 8 production Dockerfiles: Node/TypeScript, Next.js standalone, Python/FastAPI, Python/Django, PHP-FPM + nginx, Go, Rust, static site + nginx
  • 5 ready-to-run Compose stacks: app+Postgres, app+Postgres+Redis, local dev with hot reload, Caddy reverse proxy with automatic TLS, Postgres backup sidecar
  • Every Dockerfile multi-stage, non-root (numeric uid), HEALTHCHECK'd, cache-ordered, base-image pinned, with a matching .dockerignore
  • A header comment in every Dockerfile: what it builds, its build args, and the measured final image size
  • A working sample app in every stack, so `docker build .` succeeds before you change a line
  • Supporting configs, tuned and commented: nginx.conf, php-fpm.conf, php.ini, supervisord.conf, gunicorn.py, Caddyfile, backup.sh
  • 13 READMEs — one per stack plus the index — covering what each Dockerfile assumes about your app, how to adapt it, and the mistakes that stack invites
  • A tested pg_dump / pg_restore restore procedure for the backup stack
  • Commercial license — unlimited personal + client project use
FAQ

About Dockerfile & Compose Starter Pack

?

Do these actually build, or are they templates I have to fill in first?

They build. Every stack ships a small sample app — a TypeScript HTTP service, a Next.js page, a FastAPI app, a Django project, a PHP front controller, a Go service, a Rust service, a static site — so you can `cd` into any folder and run `docker build .` immediately. All 8 were built before release and the image sizes in the README came from `docker images` afterwards. Then you delete the sample and point the Dockerfile at your own code; each README lists exactly what it assumes (entrypoint, health endpoint, dependency manifest).

?

Are the image sizes real?

Yes. Every size quoted — 16.0 MB for Go, 37.9 MB for Rust, 72.2 MB for the static nginx site, 196 MB for PHP, 224 MB for Node, 272 MB for Django, 276 MB for FastAPI, 311 MB for Next.js — is `docker images` output for linux/amd64, measured on the image the shipped files build. Nothing is estimated or copied from someone else's benchmark.

?

What Docker version do I need?

Docker 20.10 or newer for the Dockerfiles. The Compose stacks use `depends_on: condition: service_healthy`, which needs Compose v1.29+ — in practice, any current `docker compose` (v2). The Go and Rust Dockerfiles use buildx's TARGETOS/TARGETARCH args for free cross-compilation, which is standard in modern Docker but degrades gracefully to amd64 defaults if unset.

?

My stack isn't in the list. Is this still useful?

Probably, if it is close to one of the eight. The patterns transfer directly: Bun and Deno follow the Node file, Flask and Litestar follow FastAPI, Laravel and Symfony follow the PHP one (its README covers the changes), Vite/Astro/Hugo output goes into the static nginx stack. If your runtime is nothing like any of these, the Compose stacks are still stack-agnostic. If it turns out not to fit, there is a 14-day refund.

?

Why is the PHP image one container running two processes?

Because single-container hosts — Fly.io, Render, App Runner, a plain `docker run` — expect one image that serves HTTP, and splitting nginx from php-fpm requires an orchestrator plus a shared socket volume. supervisord is there so that if either process dies it restarts, and so both receive a clean SIGQUIT on `docker stop`. If you want them split, the compose stacks show that shape and the PHP README explains the trade-off. It is a deliberate choice, documented, not an oversight.

?

Does it cover Kubernetes?

No. This is Dockerfiles and Compose. It does make Kubernetes easier — the images declare numeric non-root uids so `runAsNonRoot` passes, and the health endpoints map straight onto liveness and readiness probes — but there are no manifests, Helm charts or kustomize overlays in the pack. If you need those, this is not the product.

?

Is there anything unsafe I should know about before deploying?

Two things, both documented inline. First, every `.env.example` ships placeholder credentials like `change-me-before-first-run`; the stacks will start with them and you must change them. Second, `opcache.validate_timestamps = 0` in the PHP image means edits to files inside a running container have no effect — correct for immutable images, surprising if you bind-mount source. Beyond that, review anything before it reaches production: the license explicitly puts that on you, as any honest one does.

?

Can I use these in client work?

Yes. The commercial license covers unlimited personal, internal and client projects, and you can publish the container images you build from them. The one thing you cannot do is resell the pack itself or repackage it into a competing template collection.