Was docker-compose.yml ist, in einem Absatz
Ein Service ist ein Container, und eine `docker-compose.yml` ist eine Liste von Services, die zusammen laufen sollen (deine App, eine Datenbank, vielleicht ein Cache und ein Reverse-Proxy). Ein Befehl, `docker compose up`, startet den ganzen Stack, ein anderer, `docker compose down`, faehrt ihn zurueck auf null. Es ist die Standard-Art, Multi-Container-Apps auf einer einzelnen Maschine zu betreiben: Dev-Laptops, Single-Node-Prod-Server, CI-Runner.
Dieser Builder schreibt die Datei fuer dich. Preset waehlen (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, Single Redis, Single ClickHouse), Services in simplen Formularen bearbeiten, und das rechte Panel zeigt das exakte YAML, fertig zum Einfuegen in `docker-compose.yml`. Jede Option hat einen Klartext-Hinweis.
Alles laeuft im Browser. Nichts wird hochgeladen, kein Account, kein Container wird hier wirklich gestartet, der Output ist derselbe Text, den du von Hand schreiben wuerdest.
So benutzt du es
- Ein Preset oben waehlen (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, Single Redis, ClickHouse Single-Node). Das Formular fuellt sinnvolle Defaults aus, die du anpassen kannst.
- Einen Project-Namen oben setzen. Das wird das `name:`-Feld in der Datei und der Praefix der Container-Namen (keine zufaelligen Namen wie `myapp_web_1` mehr).
- Fuer jeden Service setzen: image (z. B. `nginx:alpine`), ports (host:container, wiederholbar), volumes (mit Read-only-Toggle) und environment-Variablen.
- Eine Restart-Policy waehlen: `no`, `always`, `on-failure` oder `unless-stopped`. Auf Produktivservern ist `unless-stopped` die uebliche Wahl.
- depends_on nutzen, um zu sagen "Datenbank vor App starten". Einen Healthcheck an der Datenbank ergaenzen, damit andere Services auf Ready statt auf Started warten.
- Netzwerke auf Top-Level definieren und jedem Service eines oder mehrere zuweisen. Services im selben Netz erreichen sich per Name (z. B. `db:5432`).
- Im Vorschau-Panel Copy klicken oder Download zum Speichern als `docker-compose.yml`, dann `docker compose up -d` im selben Ordner laufen lassen. Das ist der ganze Flow.
Wann das nuetzlich ist
Sieben konkrete Situationen, in denen docker-compose das Leben deutlich leichter macht:
- Ein Dev-Laptop, der Postgres, Redis und deine Node-App braucht. Eine Datei, ein `docker compose up`, dein ganzer Stack ist online. Kein Homebrew, kein apt-get, keine Versionsdrift im Team.
- Ein kleiner VPS, der ein oder zwei Apps hostet. Compose ist der einfachste Weg: Datei schreiben, `docker compose up -d`, nginx davor setzen, fertig. Kubernetes ist fuer eine Box Overkill.
- Lokales Spiegelbild der Produktion. Laeuft Prod auf Postgres 16, Redis 7 und Node 20, pinnt dieselbe compose-Datei diese Versionen auf jedem Dev-Rechner. "Funktioniert auf meinem Laptop" wird zu "funktioniert auf jedem Laptop".
- CI-Pipelines, die echte Services brauchen. Compose zieht ein echtes Postgres fuer Integrationstests in Sekunden hoch und reisst es wieder ab. Viel naeher an Prod als Mocks oder sqlite.
- Self-Hosting von Drittanbieter-Apps: WordPress, Ghost, Mastodon, NextCloud, Plausible, Gitea, n8n. Die offizielle compose-Datei ist meist der dokumentierte Install-Weg.
- Einen Stack fuer eine Demo hochziehen. Du schickst ein Repo mit einer Datei und der Reviewer tippt einen Befehl. Kein "erst Postgres 14 mit diesen Extensions installieren".
- Eine neue Datenbank ausprobieren. ClickHouse, MongoDB oder DuckDB spielen, ohne global zu installieren? `docker compose up` fuer fuenf Minuten, dann `docker compose down -v`, die Maschine ist wieder sauber.