Containerization
Packing your app plus everything it needs to run into one portable image, so it behaves the same way on almost every machine.
See it
What it is
A container packs your app together with the runtime, libraries, and system packages it needs into one image. The same image gives you the same filesystem, the same library versions, and the same entrypoint on your laptop, in CI, and in production, which kills most of the reasons builds diverge. Reproducible, though, not identical: the container borrows the host kernel, so CPU architecture, kernel features, capability and seccomp settings, mounted host paths, and resource limits still leak in. Unlike a virtual machine there is no guest OS to boot, so a container normally starts far faster than a VM and one box can run dozens.
Docker is the usual on-ramp: a Dockerfile describes the build, the result is an immutable tagged image, and a registry stores it between build and deploy. Reach for containers when your app has awkward system dependencies (ImageMagick, ffmpeg, a specific glibc), when dev and prod keep diverging, or when your platform wants an image rather than a source repo. Plenty of simple apps ship fine without one.
Gotchas that bite everyone: images balloon to a gigabyte unless you use multi-stage builds and a slim base; the layer cache is wasted if you copy the whole source before installing dependencies; the writable layer is not storage, and since containers get replaced far more often than people expect, anything written inside is gone the moment one is recreated from the image, so it belongs in a volume or object storage; and building on an Apple silicon Mac produces an arm64 image that will not start on an amd64 server.
Ask AI for it
Write a production Dockerfile for this app. Detect the runtime and package manager from the repo first, then use a multi-stage build: a builder stage that installs dev dependencies and compiles, and a slim runtime stage that copies only the built output and production dependencies. Order the layers so the dependency install is cached separately from the source copy. Run as a non-root user, pin the base image by minor version, expose the port through an env var, and add a HEALTHCHECK pointing at the health path this app actually serves. Include a .dockerignore. Then add a docker-compose file for local dev containing only the backing services the code really uses: look for a database client, a cache, a queue, an object store, and add nothing that is not there, so do not invent a database if the app does not have one. Finish with the buildx command for a linux/amd64 image built from an arm64 Mac.