Docker container

A Docker container is a process started from a Docker image and isolated from the rest of the machine: it has its own filesystem, network interface and process list, but shares the host’s kernel. The image is the read-only template (an OS base layer, runtimes, your app); the container is a running instance of it. You can start many containers from one image, and throw them away when you are done.

Example

Start a disposable Selenium Chrome node and a Postgres database for local test runs:

docker run --rm -d --name chrome -p 4444:4444 --shm-size=2g selenium/standalone-chrome:latest
docker run --rm -d --name db -p 5432:5432 -e POSTGRES_PASSWORD=test postgres:16-alpine

docker ps          # list running containers
docker logs db     # read a container's output
docker stop chrome db

--rm deletes the container when it stops, -d runs it in the background and -p host:container publishes a port. In real projects you pin image tags (for example postgres:16.4-alpine) instead of latest, so a new upstream release does not change your test environment overnight.

Why testers use containers

• Reproducible environments. The same image runs on every laptop and CI runner, which removes a whole class of “works on my machine” failures.
• Throwaway dependencies. A fresh database per test run means no leftover data from yesterday’s run.
• Parallel browsers. Selenium Grid and browser images let you scale nodes up and down with a command.
• Running the test suite itself. Playwright publishes official images with browsers and system libraries preinstalled, which avoids missing-dependency errors on CI agents.

How it differs from a virtual machine

A VM emulates a full machine with its own kernel, so it is heavier and slower to start. A container shares the host kernel, starts in seconds and uses far less memory. The trade-off is weaker isolation, which matters for security boundaries but rarely for test environments.

Common mistakes

Storing test data inside a container and expecting it to survive a restart (use volumes), using latest tags, and forgetting --shm-size for browser containers, which causes Chrome to crash under load.