Docker als Standard – Warum das für kleine Web-Apps oft übertrieben ist

Docker ist eine hervorragende Software – aber es sollte nicht der Standard für jede Bereitstellung sein. Das Internet neigt dazu, technische Debatten zu überhitzen, doch in diesem Fall geht es um ein grundlegendes Missverständnis: Werkzeuge wie Docker sind nicht für jede Aufgabe die beste Lösung.

Ich nutze Docker täglich – etwa für Datenbanken, CI-Jobs mit wiederkehrenden Abhängigkeiten oder interne Dienste, bei denen eine konsistente Umgebung entscheidend ist. Doch wenn es um kleine Webanwendungen geht, die auf einem VPS laufen sollen, wird Docker schnell zur überflüssigen Komplexität.

Warum der Standardweg immer schwerer wird

Viele moderne Bereitstellungsanleitungen verwandeln einen eigentlich simplen Prozess wie diesen:

• Anwendung bauen
• Dateien auf den Server kopieren
• Anwendung starten
• Traffic routen

in eine Abfolge von Schritten, die mit dem eigentlichen Ziel wenig zu tun haben:

• Eine Dockerfile schreiben
• Eine Basis-Image auswählen
• Build-Layer handhaben
• Ein Registry aufsetzen
• Das Image pushen und auf dem Server pullen
• Container-Netzwerk konfigurieren
• Geheimnisse mounten
• Debuggen, warum der Container abstürzt

Keiner dieser Schritte ist per se schlecht. Aber für ein kleines Projekt, das eigentlich nur laufen soll, sind sie unnötig.

Was kleine Anwendungen wirklich brauchen

Die meisten kleinen Projekte – sei es ein Nebenprojekt, ein Mini-SaaS, ein Webhook-Handler oder ein internes Dashboard – benötigen oft nur wenige grundlegende Funktionen:

• Code kompilieren oder bauen
• Prozess starten
• HTTPS bereitstellen
• Automatisches Neustarten bei Abstürzen
• Geheimnisse außerhalb des Git-Repositorys speichern
• Logs bei Fehlern einsehen
• Eventuell mehrere Anwendungen auf einem Server betreiben

Diese Anforderungen bedeuten nicht automatisch, dass alles containerisiert werden muss.

Wann Container wirklich sinnvoll sind

Docker löst echte Probleme – und das ist auch gut so. Es bietet:

• Wiederholbare Laufzeitumgebungen
• Isolation zwischen Diensten
• Vereinfachte CI/CD-Pipelines
• Ein gemeinsames Artefakt für Teams

Doch genau hier liegt das Paradox: Diese Vorteile werden oft zur Pflicht, bevor sie überhaupt gebraucht werden. Entwickler beginnen plötzlich, sich mit Themen wie Image-Größe, Build-Cache, Multi-Stage-Builds, Registry-Authentifizierung oder Container-Netzwerken zu beschäftigen – obwohl ihre Anwendung diese Komplexität nicht erfordert.

Ein VPS kann mehr als nur Container hosten

Ein VPS ist im Grunde ein vollwertiger Computer. Er kann Prozesse ausführen – und das ohne Umwege über Container. Doch die moderne Bereitstellungsphilosophie scheint zu suggerieren, dass ein Server erst dann nützlich ist, wenn er einen Container-Scheduler wie Kubernetes oder Docker Swarm ausführt.

Für viele Anwendungen reicht ein direkter Prozessbetrieb völlig aus:

bun run start node server.js ./my-go-app ./target/release/my-rust-app

Die eigentlichen Herausforderungen liegen selten in der Frage, ob Linux das Binary ausführen kann. Die Probleme entstehen meist in den Randbereichen:

• Wie erreicht Traffic die Anwendung?
• Wie wird HTTPS konfiguriert?
• Wie erfolgt ein Update ohne Ausfallzeit?
• Wohin gelangen die Logs?
• Wie werden Geheimnisse sicher injiziert?
• Wie wird die Anwendung neu gestartet?
• Wie lassen sich mehrere Anwendungen auf einem Server betreiben?

Diese Fragen betreffen die Bereitstellung im Allgemeinen – nicht zwingend Docker im Speziellen.

Der Traum: PaaS-Feeling ohne Cloud-Absicherung

Was viele Entwickler eigentlich wollen, ist das Gefühl eines Platform-as-a-Service:

Deploy

… und die Anwendung läuft. Gleichzeitig möchten sie aber die Kontrolle über einen eigenen VPS behalten: günstig, flexibel und ohne die Notwendigkeit, jedes Wochenendprojekt in eine komplexe Cloud-Architektur zu verwandeln. SSH-Zugriff, direkte Maschineninspektion und keine Abhängigkeit von externen Diensten sind hier entscheidend.

Eine ideale Bereitstellungsroute sähe für mich so aus:

1. Die Anwendung wird lokal gebaut.
2. Ein Bereitstellungstool überträgt die kompilierte Version auf den Server.
3. Der Server führt die Anwendung als normalen Prozess aus.
4. Ein Proxy leitet Anfragen zu gesunden Instanzen weiter.
5. HTTPS wird automatisch eingerichtet.
6. Logs sind zugänglich.
7. Geheimnisse werden extern verwaltet – ohne .env-Dateien im Projekt.

Keine Registry nötig. Keine Dockerfile, es sei denn, man möchte sie bewusst nutzen. Keine Container-Netzwerk-Konfiguration für eine Zwei-Routen-Webanwendung.

Tako: Ein Werkzeug für die langweilige, aber effiziente Bereitstellung

Genau in diese Lücke stoße ich mit Tako, einem kleinen Bereitstellungstool, das Anwendungen direkt auf eigenen Servern ausführt. Die Philosophie dahinter ist einfach:

• Weniger Konzepte vor dem ersten Deploy – Nicht jeder muss erst Docker, Kubernetes und Cloud-Provider verstehen, bevor er eine Anwendung online bringt.
• Weniger Infrastruktur-Dateien – Keine Dockerfiles, die nur für die Bereitstellung erstellt werden.
• Weniger bewegliche Teile – Für kleine Anwendungen reicht oft ein einfacher Prozess.
• Weniger Fehlerquellen – Weniger Komplexität bedeutet weniger Stellen, an denen etwas schiefgehen kann.
• Klare Trennung – Kein Grübeln mehr: "Ist das ein Docker-Problem oder ein Anwendungsproblem?"

Der Standard sollte zuallererst einfach sein

Es gibt eine Bereitstellungsmethode, die fast schon langweilig wirkt – aber genau das ist der Punkt:

tako init
tako servers add
tako deploy

Langweilig nicht im Sinne von schwach oder eingeschränkt, sondern weil:

• weniger Begriffe vor dem ersten erfolgreichen Deploy stehen
• weniger Dateien nur für die Infrastruktur entstehen
• weniger Komponenten für kleine Anwendungen nötig sind
• weniger versteckte Fehlerquellen existieren
• keine unnötigen Abhängigkeiten von Container-Ökosystemen bestehen

Der Standardweg sollte darauf abzielen, dass die Anwendung zuerst online kommt. Erst wenn die Anwendung wächst und tatsächlich Container benötigt, sollte man sich damit beschäftigen.

Fazit: Docker als Option, nicht als Eintrittskarte

Die Webentwicklung hat die Angewohnheit, mächtige Werkzeuge zu Pflichtwerkzeugen zu erklären. Docker ist mächtig – und verdient seinen Platz in der Toolbox. Doch es sollte nicht der erste Schritt sein, den jeder Entwickler gehen muss, bevor eine Anwendung überhaupt läuft.

Für viele Projekte bleibt der beste Bereitstellungspfad:

• Anwendung bauen
• Auf einem Server platzieren
• Ausführen
• Traffic routen
• Updates ohne Ausfallzeit durchführen

Das ist kein Rückschritt. Das ist eine sinnvolle Abstraktion. Der Standardweg sollte ruhig und unaufgeregt sein. Er sollte dem Entwickler das Gefühl geben, dass der Server ihm hilft, seine Anwendung zu betreiben – und nicht, dass er erst zum Platform-Ingenieur werden muss, bevor er überhaupt Mittagspause machen kann.