Tool im Einsatz

Docker

Die Container-Engine, die einen eigenen Server-Stack ermöglicht. Apache-2.0-lizenzierte Engine, Compose für Multi-Container-Dienste, harte Isolation zwischen Apps — eine konkrete Alternative zu nativer Installation und Cloud-SaaS.

Projekt-Profil

Docker

Container engine for application packaging and isolation

Stand: 1. Juni 2026

GitHub-Sterne

72k

Forks

19k

Offene Issues

3.8k

Lizenz

Apache-2.0

Aktuelle Version

v29.5.2

Sprache

Erstveröffentlichung

18. Januar 2013

Letzter Commit

29. Mai 2026

→ GitHub-Repository → Offizielle Website → Dokumentation

Drittquelle · Wikidata (CC0)

Wikidata-Profil

Q15206305

Lizenz

proprietäre Lizenz

Entwickler

Docker, Inc.

Initial Release

2013-03-14

→ Wikidata-Eintrag

Was ist Docker?

ist eine Container-Engine für Linux: Sie verpackt eine Anwendung samt ihrer Abhängigkeiten in ein einziges, transportables Image. Beim Start wird ein Container erzeugt — eine isolierte Laufzeit-Umgebung, die auf jedem Linux-Server mit gleicher Kernel-Version identisch funktioniert.

Der Kern ( Engine und Compose) ist Apache-2.0-lizenziert — vollwertig Open Source. Daneben gibt es kommerzielle Produkte ( Desktop, Hub Pro) — für einen Linux-Server mit Engine + Compose braucht man keines davon.

Warum ein KMU Docker nutzt

Der typische Mittelständler hat 5–15 Dienste, die nicht in die Cloud sollen oder dürfen: Wiki, Cloud-Speicher, Mailserver, Passwort-Vault, Monitoring, Workflows. Nativ installiert teilen sich die Dienste eine Ubuntu, eine Python-Version, eine PHP-Erweiterung. Ein apt-Update kann mehrere Dienste gleichzeitig stören.

Mit bekommt jeder Dienst sein eigenes Image: eigene OS-Bibliotheken, eigene Python-Version, eigenes PHP. Patches kommen pro Container, ein Update von BookStack lässt Nextcloud unberührt. Backup, Rollback und Test-Setup laufen pro Stack. Das ist die Grundlage jeder modernen KMU-Server-Architektur.

Mandantenfall

Müller Bau GmbH

Bauunternehmen, 25 Mitarbeitende, eigener Server im Büro-Schrank (Mini-PC, 64 GB RAM, 2 TB SSD). Vor zwei Jahren von nativer Ubuntu-Installation auf Compose migriert. Vorher: regelmäßige Mehrfach-Ausfälle nach Updates. Jetzt: 8 isolierte Container-Stacks, jeder mit eigenem Update-Zyklus.

Isolation der Dienste

Ein Patch oder Update eines Dienstes darf die anderen sieben nicht beeinflussen. Jeder Container hat eigene OS-Bibliotheken, eigene Runtime-Version, eigene Konfigurationsdateien.

Konfiguration als Code

Jeder Service als compose.yml in einem Git-Repo der Firma. Vollständig reproduzierbar — ein neuer Server steht in 30 Minuten, dieselbe Konfiguration läuft auf Test- und Produktivsystem.

Backups klar abgegrenzt

Persistente Daten liegen in Docker-Volumes — ein Verzeichnis pro Service. Backup ist tar czf statt /etc nach Konfigurationsdateien zu durchsuchen.

Schnelles Rollback

Image-Tag von 25.05 auf 25.04 zurücksetzen, compose up -d — alter Stand läuft in 20 Sekunden wieder. Bei nativer Installation: Ubuntu-Snapshot wiederherstellen, drei andere Dienste mitschießen.

Lokale Tests = Production-Parität

Das gleiche Image, das auf dem Server läuft, läuft im Test-Setup auf einem Notebook. Keine 'works on my machine'-Differenz mehr — derselbe Layer, derselbe Befehl, dasselbe Verhalten.

Keine SaaS-Abhängigkeit

Alle Dienste laufen auf eigenem Blech. Keine API-Quoten, keine 'Sorry, our service is down', kein 'die Preise gelten ab nächstem Quartal'. Hardware kostet einmalig, Software ist Open Source.

Acht Container, die produktiv laufen

Der konkrete Stack der Müller Bau GmbH — acht Container-Dienste auf einem einzigen Server, gemeinsam orchestriert über Compose. Jeder Stack hat sein eigenes compose.yml im Firmen-Git.

Caddy — Reverse-Proxy + Auto-SSL

Front-Server für alle Web-Dienste. Caddy terminiert HTTPS, leitet auf die internen Container weiter, holt Let's-Encrypt-Zertifikate automatisch. Eine Caddyfile für 8 Subdomains: wiki, cloud, mail, vault, status, , , agency.

Nextcloud + PostgreSQL — Datei-Cloud

Zentrale Datei-Ablage und Kalender-Sync für 25 Mitarbeitende. Nextcloud-Container greift auf eine eigene PostgreSQL-Instanz zu. Volumes für Nutzerdaten getrennt von der DB. WebDAV für Architekten-Software.

Mailcow-Stack — E-Mail-Server

Komplexer Multi-Container-Stack: Postfix, Dovecot, Rspamd, SOGo, Redis, MariaDB, Solr. 11 Container in einem Compose. Mailcow liefert das Setup als Out-of-the-box-Stack — macht's möglich.

BookStack — internes Wiki

Knowledge-Base für Bauunternehmen: Bauleiter-Checklisten, VOB-Vorlagen, Lieferanten-Kontakte, Maschinen-Wartungspläne. BookStack-Container + MariaDB-Container, zwei Volumes für Anhänge und DB.

Vaultwarden — Passwort-Manager

Bitwarden-kompatibler Passwort-Vault, . Ein einziger Container mit SQLite-Volume. Alle Mitarbeitenden synchronisieren über die offizielle Bitwarden-App gegen den eigenen Server.

Uptime Kuma — Monitoring

Container, der die anderen sieben Stacks überwacht: HTTPS-Checks auf jeden Reverse-Proxy-Endpunkt, Container-Health über die Docker-Socket-Anbindung, Notification an Bauleitung bei Ausfall.

n8n — Workflow-Automatisierung

Container für die Verbindung von Mail, Lieferanten-Portal, DATEV und internen Apps. Workflows wie 'Lieferschein per Mail → → in DATEV ablegen' laufen autonom, ausgelagert in einen separaten Stack.

Open WebUI + Ollama — lokale KI

Zwei Container: für die Modelle (Llama 3, Qwen), als Bedienoberfläche. Bauleiter chatten mit dem Wissens-Stand der eigenen Firma ( über BookStack), Daten bleiben auf dem Server.

Kern-Funktionen von Docker

Was die Docker-Engine als Container-Plattform ausmacht — und welche Funktionen für ein KMU-Setup besonders tragend sind.

Container-Isolation

Linux-cgroups und Namespaces garantieren, dass ein Container weder die Ressourcen noch das Dateisystem oder Netzwerk eines anderen sehen kann. Ein gebrochener Container reißt nichts mit.

Docker Compose — Multi-Container-Stacks

Eine YAML-Datei beschreibt einen ganzen Service-Stack: Container, Volumes, Netzwerke, Abhängigkeiten, Restart-Policies. compose up -d, fertig. Versionierbar im Git, reproduzierbar auf jedem Server.

Volumes — persistente Daten

Container sind ephemer, Volumes sind dauerhaft. Datenbanken, Uploads, Konfigurationsstände liegen in benannten Volumes oder Bind-Mounts — Container kann gelöscht werden, Daten bleiben.

Networking — eigene Bridge-Netze

Pro Stack ein eigenes virtuelles Netzwerk. Container im selben Stack erreichen sich per Hostnamen (db, redis, app). Cross-Stack-Kommunikation nur über explizit definierte Frontend-Netze — saubere Trennung.

Image-Layering und Cache

Images bestehen aus Layern; identische Layer (z. B. Debian-Base) werden geteilt. 8 Container teilen sich die Base-Images — Plattenplatz spart Faktor 5–10 im Vergleich zu vollständigen VMs.

docker stats / logs — Standard-Observability

Eingebaute Befehle für CPU-, RAM-, Netz-Last pro Container, dazu strukturierte Logs. oder setzen darauf auf, aber für den schnellen Check reicht die CLI.

Alternativen ehrlich verglichen

Wenn Docker nicht passt — was sonst?

Drei Alternativen für Container und Isolation — jede mit eigenem Profil. Hier die Einordnung ohne Verkaufs-Romantik.

Daemonless

Podman

Red Hat, Apache-2.0

+ Kein Hintergrund-Daemon, rootless out-of-the-box
+ Drop-in-kompatibel mit Docker-Befehlen
− Compose-Support später dazu gekommen, weniger ausgereift
− Kleinere Community, weniger Stack-Vorlagen

System-Container

LXC / LXD

Canonical, Apache-2.0

+ Vollständige System-Container (eigener init, mehrere Services)
+ Sehr ressourcen-effizient für VM-Ersatz
− Andere Denke (System statt App-Container)
− Kein vergleichbarer Image-Hub wie Docker Hub

Virtualisierung

Proxmox VE / KVM

Proxmox, AGPL-3.0

+ Vollständige Hardware-Isolation per VM
+ Eigener Kernel pro Workload möglich
− Höherer Ressourcen-Verbrauch (RAM, Disk)
− Update-Zyklen wie bei nativer Installation

Faustregel: ist der pragmatische Default — die größte Community, die meiste Doku, die meisten Out-of-the-box-Stacks. Podman ist die richtige Wahl für RHEL/Fedora-Houses, die ohne Daemon arbeiten wollen. VMs bleiben sinnvoll, wenn unterschiedliche Kernel-Versionen oder echte Hardware-Isolation gefordert sind.

Pricing

Apache-2.0 für die Engine. Sternchen bei Docker Desktop.

Lizenz

Docker Engine + Docker Compose: Apache-2.0, vollständig Open Source. Docker Desktop (macOS/Windows-GUI): proprietär, ab 250 Mitarbeitenden oder 10 Mio. $ Umsatz kostenpflichtig. Docker Hub Pro: kommerziell. Für Linux-Server mit Engine + Compose: keine Lizenzkosten.

Laufende Kosten

Hardware-only. Ein Mini-PC mit 32–64 GB RAM und 2 TB SSD reicht für einen kompletten KMU-Stack — Anschaffung 1.500–2.500 €. Strom: ca. 100 €/Jahr. Keine Cloud-Gebühren, keine Per-Container-Lizenz.

Aufwand

Docker Engine installieren: 10 Minuten (apt install). Erster Container: 5 Minuten. KMU-Komplettsetup mit 8 Container-Stacks, Reverse-Proxy, Backup-Routine und Mitarbeiter-Schulung: 5–10 Beratungstage.

Wichtig zur Klarheit: = die Engine + Compose, Apache-2.0, kostenlos auf Linux-Server. Desktop und Hub Pro sind eigene, kommerzielle Produkte derselben Firma — für einen klassischen KMU-Server-Stack braucht man keines davon. Wer auf macOS oder Windows entwickelt: Colima oder Rancher Desktop sind freie Alternativen zu Desktop.

Backup-Routine — alle Container-Volumes wöchentlich

#!/bin/bash
# Wöchentliches Backup aller 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/

Wöchentliches Volume-Backup, Stack-Shutdown nur für die Sicherungs-Dauer, Restore via tar xzf. Quelle: Eigene Praxis, Public Domain.

Beispiel-compose.yml — BookStack-Wiki mit 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:

Ein einzelner Stack: BookStack-Container + eigene MariaDB-Instanz, getrennte Netze für Frontend und Datenbank, persistente Volumes. Quelle: Eigene Praxis, MIT-Compose-Snippet.

Verwandte Themen

Docker ist die Grundlage — was läuft drauf?

ist das Fundament. macht die Verwaltung grafisch, Caddy ist der Reverse-Proxy davor, und sind nur zwei der typischen Container-Apps:

→ Portainer (Container-Verwaltung im Browser)→ Caddy (Reverse-Proxy für die Container)→ Übersicht aller Tools

Bereit für den nächsten Schritt?

Kostenloses Erstgespräch. Unverbindlich. In 30 Minuten wissen Sie, ob und wie KI Ihrem Unternehmen helfen kann.

Erstgespräch buchen Förderfähigkeit prüfen