Tool in production

Docker

The container engine that gives an SMB its own server stack. Apache-2.0 licensed engine, Compose for multi-container services, hard isolation between apps — a concrete alternative to native installation and cloud SaaS.

Project profile

Docker

Container engine for application packaging and isolation

As of: June 1, 2026

GitHub stars

72k

Forks

19k

Open issues

3.8k

License

Apache-2.0

Latest version

v29.5.2

Language

First release

January 18, 2013

Last commit

May 29, 2026

→ GitHub repository → Official website → Documentation

Third-party source · Wikidata (CC0)

Wikidata profile

Q15206305

License

proprietary license

Developer

Docker, Inc.

Initial release

2013-03-14

→ Wikidata entry

What is Docker?

is a container engine for Linux: it packages an application together with its dependencies into a single, portable image. At start time a container is created — an isolated runtime that behaves identically on every Linux server with the same kernel version.

The core ( Engine and Compose) is licensed under Apache-2.0 — full open source. Alongside that there are commercial products ( Desktop, Hub Pro) — for a Linux server with Engine + Compose you need none of them.

Why an SMB uses Docker

A typical SMB has 5–15 services that should not — or must not — live in the cloud: wiki, file storage, mail server, password vault, monitoring, workflows. Installed natively, these services share one Ubuntu, one Python version, one PHP extension. A single apt update can disturb several services at once.

With every service gets its own image: its own OS libraries, its own Python, its own PHP. Patches arrive per container, a BookStack update leaves Nextcloud untouched. Backup, rollback and test setup run per stack. This is the foundation of any modern SMB server architecture.

Client case study

Müller Bau GmbH

Construction company, 25 employees, own server in the office cabinet (mini PC, 64 GB RAM, 2 TB SSD). Migrated from a native Ubuntu installation to Compose two years ago. Before: repeated multi-service outages after updates. Now: 8 isolated container stacks, each with its own update cycle.

Service isolation

A patch or update of one service must not affect the other seven. Each container has its own OS libraries, its own runtime version, its own configuration files.

Configuration as code

Every service as a compose.yml in the company's Git repo. Fully reproducible — a new server is up in 30 minutes, the same configuration runs on test and production.

Backups cleanly scoped

Persistent data lives in volumes — one directory per service. Backup is tar czf instead of scanning /etc for configuration files.

Fast rollback

Reset image tag from 25.05 back to 25.04, compose up -d — the previous state is back up in 20 seconds. With a native install: restore an Ubuntu snapshot and break three other services along the way.

Local tests = production parity

The exact image that runs on the server runs in the test setup on a laptop. No more 'works on my machine' divergence — same layer, same command, same behaviour.

No SaaS dependency

Every service runs on hardware you own. No quotas, no 'sorry, our service is down', no 'prices apply from next quarter'. Hardware is a one-off cost, software is open source.

Eight containers in production

The concrete stack at Müller Bau GmbH — eight container services on a single server, orchestrated via Compose. Each stack has its own compose.yml in the company Git.

Caddy — reverse proxy + auto-SSL

Front server for all web services. Caddy terminates HTTPS, routes to the internal containers, fetches certificates automatically. One Caddyfile for 8 subdomains: wiki, cloud, mail, vault, status, , , agency.

Nextcloud + PostgreSQL — file cloud

Central file storage and calendar sync for 25 staff. The Nextcloud container connects to its own instance. Volumes for user data kept separate from the DB. WebDAV for architects' software.

Mailcow stack — mail server

Complex multi-container stack: Postfix, Dovecot, Rspamd, SOGo, Redis, MariaDB, Solr. 11 containers in one Compose. Mailcow ships the setup as an out-of-the-box stack — makes that possible.

BookStack — internal wiki

Knowledge base for a construction company: site-manager checklists, VOB templates, supplier contacts, machine maintenance schedules. BookStack container + MariaDB container, two volumes for attachments and DB.

Vaultwarden — password manager

Bitwarden-compatible password vault, . A single container with an SQLite volume. All staff sync via the official Bitwarden app against the firm's own server.

Uptime Kuma — monitoring

Container that monitors the other seven stacks: HTTPS checks on every reverse-proxy endpoint, container health via the socket binding, notification to site management on failure.

n8n — workflow automation

Container for connecting mail, supplier portals, DATEV and internal apps. Workflows like 'delivery note by mail → → file into DATEV' run autonomously, isolated in their own stack.

Open WebUI + Ollama — local AI

Two containers: for the models (Llama 3, Qwen), as the front-end. Site managers chat with the firm's own knowledge ( over BookStack), data stays on the server.

Core capabilities of Docker

What defines the engine as a container platform — and which capabilities matter most in an SMB setup.

Container isolation

Linux cgroups and namespaces guarantee that a container can see neither the resources nor the filesystem or network of another. A broken container does not bring others down.

Docker Compose — multi-container stacks

A single YAML file describes a whole service stack: containers, volumes, networks, dependencies, restart policies. compose up -d, done. Versioned in Git, reproducible on any server.

Volumes — persistent data

Containers are ephemeral, volumes are durable. Databases, uploads, configuration state live in named volumes or bind mounts — the container can be deleted, the data stays.

Networking — own bridge networks

One virtual network per stack. Containers in the same stack reach each other by host name (db, redis, app). Cross-stack communication only over explicitly defined frontend networks — clean separation.

Image layering and cache

Images consist of layers; identical layers (e.g. a Debian base) are shared. Eight containers share base images — disk usage is 5–10× lower than for full VMs.

docker stats / logs — standard observability

Built-in commands for per-container CPU, RAM, network load plus structured logs. or sit on top, but for a quick check the CLI is enough.

Honest alternatives

If Docker is not a fit — what else?

Three alternatives for containers and isolation — each with its own profile. Honest framing here — no marketing romance.

Daemonless

Podman

Red Hat, Apache-2.0

+ No background daemon, rootless out of the box
+ Drop-in compatible with Docker commands
− Compose support came later, less mature
− Smaller community, fewer stack templates

System containers

LXC / LXD

Canonical, Apache-2.0

+ Full system containers (own init, multiple services)
+ Very resource efficient as a VM replacement
− Different mental model (system vs. app containers)
− No image hub comparable to Docker Hub

Virtualisation

Proxmox VE / KVM

Proxmox, AGPL-3.0

+ Full hardware isolation via VM
+ Separate kernel per workload possible
− Higher resource cost (RAM, disk)
− Update cycles like a native installation

Rule of thumb: is the pragmatic default — the largest community, the most documentation, the most out-of-the-box stacks. Podman is the right choice for RHEL/Fedora houses that want to work without a daemon. VMs stay sensible when different kernel versions or real hardware isolation are required.

Pricing

Apache-2.0 for the engine. Asterisks on Docker Desktop.

License

Docker Engine + Docker Compose: Apache-2.0, full open source. Docker Desktop (macOS/Windows GUI): proprietary, paid above 250 employees or $10M revenue. Docker Hub Pro: commercial. For a Linux server with Engine + Compose: no license fees.

Running costs

Hardware only. A mini PC with 32–64 GB RAM and 2 TB SSD is enough for a complete SMB stack — acquisition 1,500–2,500 €. Electricity: around 100 €/year. No cloud fees, no per-container licence.

Effort

Install Docker Engine: 10 minutes (apt install). First container: 5 minutes. Complete SMB setup with 8 container stacks, reverse proxy, backup routine and staff training: 5–10 consulting days.

Important for clarity: = the engine + Compose, Apache-2.0, free on Linux servers. Desktop and Hub Pro are separate, commercial products from the same company — for a classic SMB server stack you need none of them. For developers on macOS or Windows: Colima or Rancher Desktop are free alternatives to Desktop.

Backup routine — all container volumes, weekly

#!/bin/bash
# Weekly backup of all Docker volumes
BACKUP=/srv/backup/$(date +%Y-%m-%d)
mkdir -p $BACKUP

cd /srv/stack && docker compose down

for vol in $(docker volume ls -q); do
  tar czf $BACKUP/$vol.tgz \
    -C /var/lib/docker/volumes/$vol .
done

docker compose up -d
rclone copy $BACKUP nas:backups/server-stack/

Weekly volume backup, stack only down for the duration of the snapshot, restore via tar xzf. Source: own practice, public domain.

Example compose.yml — BookStack wiki with MariaDB

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:25.05
    container_name: bookstack
    environment:
      - APP_URL=https://wiki.muellerbau.de
      - DB_HOST=bookstack-db
      - DB_USER=bookstack
      - DB_PASS=${BOOKSTACK_DB_PASS}
    volumes:
      - ./bookstack-data:/config
    depends_on:
      - bookstack-db
    restart: unless-stopped
    networks:
      - frontend
      - bookstack-net

  bookstack-db:
    image: mariadb:11
    container_name: bookstack-db
    environment:
      - MYSQL_ROOT_PASSWORD=${BOOKSTACK_ROOT_PASS}
      - MYSQL_DATABASE=bookstack
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=${BOOKSTACK_DB_PASS}
    volumes:
      - ./bookstack-db:/var/lib/mysql
    restart: unless-stopped
    networks:
      - bookstack-net

networks:
  frontend:
    external: true
  bookstack-net:

A single stack: BookStack container + its own MariaDB instance, separate networks for frontend and database, persistent volumes. Source: own practice, MIT Compose snippet.

Docker is the foundation — what runs on it?

is the bedrock. adds graphical management, Caddy is the in front, and are just two of the typical container apps:

→ Portainer (container management in the browser)→ Caddy (reverse proxy for the containers)→ Overview of all tools

Ready for the next step?

Free intro call, no strings attached. In 30 minutes you'll know whether and how AI can help your business.

Book a call Check eligibility