container runtime Introduced in L7

Docker

The container runtime that defined modern packaging. Build once, run anywhere — for real.

Mindmap

hover · click to navigate
this tech depends on / used by alternative Shipyard anchor
What it is

The plain-English version

Docker packages applications into containers — bundles of code, libraries, and OS pieces — that run identically anywhere. The image (static blueprint) is built from a Dockerfile and stored in a registry; the container (running instance) starts from the image. Docker the company commercialized container tech around 2013 and shaped the modern build/ship/run flow.

Why it exists

The problem it solves

Containers solved "works on my machine." The same image runs on a developer laptop, a CI runner, and a production cluster — byte-identical. They're the unit Kubernetes orchestrates. Even if you never run a Dockerfile yourself, your CI/CD probably does.

What it competes with

Alternatives

AlternativeTypeWhen it wins
KubernetesorchestratorThe container orchestrator. Powerful, complex, the de facto standard for running containers at scale.
Where it shows up in Shipyard

Deep links

Vocabulary

The words you'll hear

Dockerfile
The recipe. Text file with build instructions.
Image
Static read-only artifact built from a Dockerfile.
Container
Running instance of an image.
Layer
Each Dockerfile instruction creates a layer. Cached and reused on rebuild.
Registry
Where images live. Docker Hub, GitHub Container Registry (ghcr.io), AWS ECR, Cloudflare R2.
Multi-stage build
Build in one stage with full toolchain; copy only the artifact to a slim runtime stage. Smaller images.
Compose
Local multi-container orchestration with YAML. Great for dev, not for production.
Prompting

Bad vs. good prompt for Docker

✕ Bad prompt
containerize this
✓ Good prompt
Write a multi-stage Dockerfile for this Next.js 14 app. Stage 1: install deps with npm ci. Stage 2: build. Stage 3: alpine-based runtime with only production deps. Use a non-root user in the runtime stage. Include a HEALTHCHECK. Target image size under 200MB. Show me the .dockerignore too.

Why it works: Specifies multi-stage (the right pattern), security (non-root), operational hygiene (healthcheck), size budget, and the often-missed .dockerignore. Teaches the agent to ship a real-world Dockerfile, not the bare-minimum one.

Pitfalls

What bites real teams

⚠ Running as root

The default. A container compromise becomes a host concern. Use USER appuser in your Dockerfile.

⚠ Bloated images

Forgetting multi-stage means you ship the build toolchain to production. 1GB images become 150MB with multi-stage.

⚠ Caching gone wrong

Putting COPY . . before npm ci invalidates the dependency cache on every commit. Order layers from least-to-most-changing.

References

Official docs only