Knowledge base
Containers & Orchestration
Running software in images instead of installs: Docker, Podman, Portainer, and Kubernetes, with the image hygiene, daemon security, and upgrade discipline that decide whether containers help ops or complicate them.
5 topics · 5 articles
- Docker: The Container Engine Everything Else Copies
Docker made containers a vernacular: images, registries, and a CLI that turned 'works on my machine' into a packaging question. It…
- Podman: Containers Without the Daemon
Podman is Red Hat's container engine built on the no-daemon answer to Docker's biggest architectural weakness: containers run as c…
- Docker vs Podman: Which Engine Belongs on Your Servers?
Docker and Podman both implement containers, OCI images, and largely the same CLI, so the choice is not capability: it is architec…
- Portainer: The Container Management GUI
Portainer is the web GUI in front of Docker, Docker Swarm, and Kubernetes environments: stacks built from compose files, per-conta…
- Kubernetes: The Orchestrator, Argued Honestly
Kubernetes is the container orchestrator that became infrastructure's default big-system substrate: deployments, services, ingress…
Field notes
Containers changed where complexity lives: packaging and runtime moved into images and registries, while security moved to the boundary between container and host kernel. Neither Docker nor Podman nor Kubernetes removes the need to understand what a container actually is, and the teams that fail with them are usually the ones treating images as magic.
This category covers the engine choice (Docker vs Podman), the management layer (Portainer), and the orchestrator decision (Kubernetes, including the honest answer that most small hosting estates should not run it). The discipline that carries across all four: digest pinning, image scanning, resource caps, and staged upgrades.
Related areas
Related services
Server problem? Hacked site? Slow website?
Critical issues answered within 30 minutes, 24 hours a day, 7 days a week.