Docker in plain words

Docker borrowed its name and its whole idea from shipping containers. Before standardized containers, loading a ship meant handling every crate, barrel, and sack differently. A container made the outside uniform: any crane, truck, or ship could move it without caring what was inside.

Software has the same old problem. An app that works perfectly on the developer's laptop can fail on your server because of a different operating system version, a missing library, or a conflicting version of something else already installed. A container packages the app together with everything it needs to run, its exact dependencies, its own tiny file system, all of it, so it behaves the same wherever it runs.

An image is the packaged blueprint: a read-only snapshot of an app and everything it needs, downloaded once from somewhere like Docker Hub or GitHub's registry. A container is a running instance of that image, the thing actually doing work on your server.

This distinction matters in practice. You can stop a container, delete it, and start a fresh one from the same image in seconds, without re-downloading anything. That's also why "did you restart it?" is such a common fix in self-hosting: restarting a container just makes a new instance from the same known-good blueprint.

Most real apps need more than one container. Every guide on this site so far has shown you a docker-compose.yml file: a plain text description of every container an app needs (the app itself, its database, maybe a cache), how they talk to each other, and where their data lives on disk.

Instead of starting each piece by hand in the right order, you write it down once and run docker compose up -d. Docker reads the file, starts everything it describes, and wires the containers together so they can reach each other by the names you gave them, exactly what you've been doing in every tool guide on this site.

It's tempting to think of a container as a locked box, fully isolated from everything else on the server. That's not quite right, and it matters for how carefully you treat what runs inside one.

Containers share the host server's kernel, the core of the operating system. The isolation between them is real and useful for keeping apps tidy and out of each other's way, but it's not designed to hold off a determined attacker the way a fully separate virtual machine would. A vulnerability in the container software itself, or a container deliberately run with extra privileges, can in principle reach beyond its box.

None of this means containers are unsafe to use, the tool guides on this site lean on them throughout. It means the same basic habits from the rest of this site still apply inside containers too: keep images updated, don't run things with more privileges than they need, and don't treat "it's in a container" as a reason to skip the firewall and backup steps from earlier in this series.

Ten years ago, getting a piece of software running reliably meant matching library versions, editing config files by hand, and hoping nothing else on the server conflicted with it. Docker Compose turned most of that into a text file you can read top to bottom, and an AI can read right along with you.

When a container refuses to start, the error message it prints is usually specific enough to paste directly into a chat and ask what it means, exactly the habit the get-started guide walks through. That's the real shift: not that containers are new, they've been mainstream for over a decade, but that the last mile of understanding what one is telling you no longer requires years of experience to close.