Wie Container vom Laptop auf echte Server kommen

Freitagmorgen, 10 Uhr, ein Dresdner Softwarehaus mit zwölf Entwicklern. Ihre neue Projektmanagement-Plattform läuft seit drei Monaten fehlerfrei auf den Laptops des Teams. Vier Container: eine React-Frontend-App, ein Python-API-Server, PostgreSQL und Redis. Docker Compose startet den Stack in 20 Sekunden. Dann fragt der Geschäftsführer: „Wann geht das live?“

Was „live“ bedeutet, bestimmt den Aufwand. Für die ersten 50 Kunden reicht ein einzelner Server, während 5.000 gleichzeitige Nutzer eine völlig andere Infrastruktur verlangen. Und der Weg vom funktionierenden Compose-Stack zum produktionsreifen Deployment ist länger, als die meisten Teams erwarten, weil neben dem reinen Code dutzende Infrastrukturdetails geklärt werden müssen. HTTPS-Zertifikate, ein Reverse Proxy, automatische Deployments bei jedem Git-Push, Health Checks, Log-Aggregation, eine Container-Registry für die fertigen Images. Dieser Teil zeigt den Weg vom Laptop zum ersten echten Server und klärt, wann der Einzelserver nicht mehr ausreicht.

Einzelserver-Deployment: Unterschätzter Klassiker

Nicht jedes Projekt braucht ein Cluster. Ein einzelner VPS mit Docker Compose in der Produktion ist kein Provisorium, sondern für viele Anwendungsfälle die richtige Architektur. Ein Hetzner CX33 mit vier vCPUs und 8 GB RAM kostet 5,49 Euro im Monat (Stand Februar 2026, vor der angekündigten Preiserhöhung von 30 bis 37 Prozent ab April 2026). Auf dieser Hardware laufen ein API-Server, eine Datenbank, ein Cache und ein Reverse Proxy problemlos nebeneinander.

37signals, das Unternehmen hinter Basecamp und Ruby on Rails, hat jahrelang Millionen Nutzer von wenigen, überschaubaren Servern bedient. Im Oktober 2022 kündigten die Gründer den Abschied von der Cloud an und rechnen nach eigenen Angaben mit Einsparungen von über zehn Millionen Dollar in fünf Jahren, weshalb sich seitdem eine wachsende Gegenbewegung zur automatischen Cloud-Migration formiert hat. Ein Extrembeispiel. Aber der Punkt bleibt: Ein einzelner gut konfigurierter Server trägt mehr Last, als viele Teams vermuten.

Zu viele Teams skalieren zu früh, weil sich Kubernetes besser im Lebenslauf macht als ein VPS mit Compose. Pragmatismus schlägt Architektur-Astronautentum. Immer.

Mit wenigen Anpassungen lässt sich der Compose-Stack aus der Entwicklung direkt auf dem Server einsetzen. Volumes zeigen auf persistente Verzeichnisse statt auf den lokalen Quellcode. Port-Bindungen ändern sich: Statt Port 3000 auf dem Laptop lauscht der Reverse Proxy auf Port 80 und 443, während die .env-Datei Produktions-Credentials statt lokaler Testwerte enthält. Restart-Policies stellen sicher, dass Container nach einem Serverreboot automatisch wieder hochkommen. Ein Detail, das beim ersten Stromausfall über Wochenende den Unterschied macht.

Wann reicht ein einzelner Server?

Länger, als die meisten denken. Ein CX33 mit vier vCPUs verarbeitet bei einer typischen Webanwendung einige hundert Anfragen pro Sekunde, was tausenden gleichzeitiger Nutzer entspricht. Erst wenn die CPU dauerhaft über 70 Prozent ausgelastet ist oder der RAM knapp wird, lohnt sich der Blick auf vertikale Skalierung (größerer Server) oder horizontale Skalierung (mehrere Server), obwohl viele Anwendungen diesen Punkt in der Praxis nie erreichen.

Ein klares Signal für den Wechsel: Wenn die Anwendung Ausfälle nicht tolerieren kann, weil ein einzelner Server immer einen Single Point of Failure bedeutet. Geht die Hardware kaputt oder schlägt ein Betriebssystem-Update fehl, steht die gesamte Anwendung still, sofern kein zweiter Server als Fallback bereitsteht. Für ein internes Werkzeug ist das akzeptabel. Für eine kundenseitige SaaS-Plattform nicht.

Welcher Reverse Proxy passt zu Containern?

Jede öffentlich erreichbare Webanwendung braucht einen Reverse Proxy. Er nimmt alle eingehenden HTTP-Anfragen entgegen, leitet sie an den richtigen Dienst weiter und kümmert sich um HTTPS-Verschlüsselung. In der klassischen Serverwelt war Nginx dafür die erste Wahl. In Container-Umgebungen hat Traefik diese Rolle übernommen.

Traefik erkennt neue Container automatisch. Startet ein neuer Dienst, registriert Traefik ihn und erstellt die passende Weiterleitung. Bei Nginx müsste dafür die Konfiguration manuell angepasst und der Dienst neu geladen werden. In einem Compose-Stack mit fünf Diensten ist das noch überschaubar. In einem Cluster mit 30 Diensten, die regelmäßig aktualisiert werden, wird manuelle Konfiguration zum Engpass.

Docker-Labels auf den Containern genügen, um Routing-Regeln zu definieren, HTTPS zu aktivieren und Lastverteilung einzurichten, sodass die gesamte Konfiguration in der Compose-Datei lebt, statt über separate Verzeichnisse und Template-Sprachen verstreut zu sein. Kein Reload-Skript, keine manuellen Eingriffe nach jedem Update. Traefik hat Nginx für Container-Deployments praktisch abgelöst, und das zurecht. Allein die dynamische Service-Erkennung spart so viel manuelle Arbeit, dass der Umstieg sich nach dem ersten Deployment rechtfertigt.

Neben dem Routing bietet Traefik Middlewares, die sich ebenfalls per Docker-Label aktivieren lassen. Rate Limiting begrenzt die Anzahl der Anfragen pro IP-Adresse und schützt die Anwendung vor Brute-Force-Angriffen, während IP-Whitelisting den Zugang zu Admin-Bereichen auf bestimmte Adressbereiche einschränkt. Beide Funktionen erfordern bei Nginx zusätzliche Konfigurationsdateien und einen Reload, während Traefik sie als Label direkt am betroffenen Container definiert. Für Anwendungen mit authentifizierten Bereichen lohnt sich ein Blick auf die Forward-Auth-Middleware, die Anfragen erst an einen externen Authentifizierungsdienst weiterleitet, bevor sie den eigentlichen Container erreichen.

Caddy ist eine dritte Option, die in den letzten Jahren Anhänger gewonnen hat, weil automatisches HTTPS von Haus aus funktioniert und die Konfigurationssprache deutlich einfacher ist als bei Traefik. Für Setups mit zwei oder drei Diensten ist Caddy eine gute Wahl. Sobald dynamisches Routing, mehrere Domains und automatische Service-Erkennung ins Spiel kommen, ist Traefik allerdings die bessere Wahl, weil die native Docker-Integration und das Label-basierte Routing bei komplexeren Stacks weniger Aufwand verursachen.

Wie funktioniert automatische Zertifikatsverwaltung?

HTTPS ist keine Option mehr. Browser markieren HTTP-Seiten als unsicher, Suchmaschinen bevorzugen HTTPS in ihren Rankings. Let’s Encrypt stellt kostenlose TLS-Zertifikate aus, die 90 Tage gültig sind. Traefik übernimmt den gesamten Prozess automatisch: beantragen, validieren, installieren, erneuern. Kein manueller Eingriff nötig.

Unter der Haube nutzt der Validierungsprozess das ACME-Protokoll, wobei bei der HTTP-01-Challenge Traefik eine spezielle Datei unter einer definierten URL platziert, die Let’s Encrypt abruft. Bei Einzelservern funktioniert das zuverlässig. Für Wildcard-Zertifikate oder Setups hinter einem Load Balancer braucht es die DNS-01-Challenge, bei der Traefik stattdessen einen DNS-Eintrag beim Hosting-Provider setzt, sodass beide Varianten vollautomatisch laufen, sobald sie einmal konfiguriert sind.

In Kubernetes-Umgebungen übernimmt cert-manager die gleiche Aufgabe, weil er als eigenständiger Controller Zertifikate überwacht, sie automatisch 30 Tage vor Ablauf erneuert und als Kubernetes Secrets speichert. Seit cert-manager und Let’s Encrypt zusammenspielen, sind kommerzielle Zertifikatsanbieter für die meisten Anwendungsfälle überflüssig geworden. Wer heute noch hunderte Euro pro Jahr für SSL-Zertifikate bezahlt, sollte dringend seine Infrastruktur überprüfen.

CI/CD: Vom Git-Push zum laufenden Container

Manuelles Deployment funktioniert so: SSH auf den Server, git pull, docker compose build, docker compose up. Fünf Minuten Arbeit, die bei jedem Durchlauf fehleranfällig bleibt. Vergessene Umgebungsvariablen, ein versehentlich übersprungener Build-Schritt, ein alter Image-Cache, der Probleme verursacht. Jedes Team, das länger als einen Monat manuell deployt, erzählt die gleiche Geschichte: Irgendwann geht etwas schief, und niemand kann nachvollziehen, welcher Schritt gefehlt hat.

Continuous Integration und Continuous Deployment automatisieren diesen Prozess. Eine typische CI/CD-Pipeline für Container-Anwendungen besteht aus vier Stufen. Erstens: Build und Tests. Im ersten Schritt baut das Docker-Image und führt alle Tests aus. Scheitern die Tests, bricht der Prozess ab.

Zweitens: Security Scanning. Werkzeuge wie Trivy oder Grype prüfen das Image auf bekannte Schwachstellen in Betriebssystempaketen und Anwendungsbibliotheken. Drittens: Registry-Push. Das fertige Image wird in eine Container-Registry geschoben. Viertens: Deployment. Zuletzt verbindet sich die Pipeline zum Zielserver und startet die Container mit dem neuen Image.

Was bringen Multi-Stage Builds für die Pipeline?

Multi-Stage Builds trennen die Build-Umgebung vom Produktions-Image. Im ersten Stage werden Abhängigkeiten installiert, Quellcode kompiliert und Assets gebaut. Im zweiten Stage landet nur das fertige Artefakt in einem minimalen Basis-Image. Eine typische Node.js-Anwendung mit Build-Werkzeugen, Testframeworks und Dev-Dependencies erzeugt ein Build-Image von 1,2 GB. Das Produktions-Image mit Multi-Stage: 150 MB. Weniger Dateien bedeuten weniger Angriffsfläche. Kein Compiler, kein Paketmanager, keine Build-Werkzeuge im Produktionscontainer.

In der CI/CD-Pipeline ergibt sich ein weiterer Vorteil: kleinere Images beschleunigen den Push in die Registry und den Pull auf dem Zielserver. Bei langsamen Netzwerkverbindungen zwischen CI-Runner und Produktionsserver kann der Unterschied zwischen 1,2 GB und 150 MB ein Deployment um mehrere Minuten verkürzen. Klingt nach wenig. Ist es nicht, wenn das Team zehnmal am Tag deployt.

GitHub Actions oder GitLab CI?

GitHub Actions und GitLab CI sind die beiden verbreitetsten Werkzeuge für CI/CD, wobei die Wahl weniger von den Features abhängt als vom bestehenden Setup des Teams. GitHub Actions nutzt YAML-Workflow-Dateien im Verzeichnis .github/workflows des Repositories. Jeder Workflow definiert Trigger (Push auf main, Pull Request, manuell), Jobs und Schritte. Öffentliche Runner stellt GitHub kostenlos bereit: 2.000 Minuten pro Monat im Free-Tier, 3.000 im Team-Plan. Für Docker-Builds reicht das bei kleinen Teams, solange die Images nicht bei jedem Push 15 Minuten kompilieren.

GitLab CI arbeitet mit einer einzelnen .gitlab-ci.yml-Datei und bietet eine integrierte Container-Registry, weshalb der Build-Push-Schritt deutlich einfacher wird, weil Image-Build und Registry im gleichen System laufen. Für selbst gehostete Git-Instanzen bietet GitLab CI das bessere Gesamtpaket, weil Runner auf eigenen Servern laufen und keine Abhängigkeit von externen Diensten entsteht. Preislich ist GitLab mit 400 kostenlosen CI-Minuten im Free-Tier knapper aufgestellt als GitHub, bietet aber im Premium-Plan für 29 Dollar pro Nutzer und Monat deutlich mehr integrierte Sicherheitsfunktionen wie SAST und Dependency Scanning.

Ein Punkt, den viele übersehen: Security Scanning gehört in die Pipeline, nicht in ein Backlog-Ticket für „später“. Trivy scannt ein Docker-Image in unter 30 Sekunden auf bekannte CVEs, und die Integration in GitHub Actions oder GitLab CI braucht fünf Zeilen YAML. Trotzdem bauen die meisten Teams Security Scanning erst ein, nachdem der erste Audit unangenehme Fragen aufgeworfen hat. Das ist fahrlässig. Ein Image mit einer bekannten Remote-Code-Execution-Schwachstelle in Produktion zu schieben, weil niemand geprüft hat, ist vermeidbar.

Container-Registries: Wohin mit den fertigen Images?

Zwischen Build und Deployment steht die Container-Registry. Sie speichert die fertigen Docker-Images und stellt sie für den Pull auf dem Zielserver bereit. Ohne Registry gibt es kein automatisiertes Deployment. Manuell gebaute Images per SCP auf den Server zu kopieren, funktioniert genau einmal, bevor jemand die falsche Version hochlädt.

Docker Hub war jahrelang die Standard-Registry. Dann kamen die Einschränkungen. Seit April 2025 limitiert Docker Hub anonyme Pulls auf zehn pro Stunde, authentifizierte Pulls im kostenlosen Tarif auf 100 pro Stunde. Für eine CI/CD-Pipeline, die bei jedem Commit baut und pulled, reicht das an aktiven Entwicklungstagen nicht aus. Private Repositories kosten ab 9 Dollar pro Monat. Das ist nicht viel, aber unnötig, wenn es kostenlose Alternativen gibt.

Für die meisten Teams ist GHCR (GitHub Container Registry) die pragmatischste Wahl, weil öffentliche Repositories komplett kostenlos sind und private Repositories im bestehenden GitHub-Plan enthalten sind. Images leben direkt neben dem Quellcode, Zugriffsrechte werden über die bestehenden GitHub-Berechtigungen gesteuert, und in GitHub Actions genügt ein einzelnes GITHUB_TOKEN für die Authentifizierung. Beim Speicherplatz bietet GitHub im Free-Tier 500 MB, im Team-Plan 2 GB. Die Grenzen lassen sich mit Versionierungs-Tags und regelmäßigem Aufräumen alter Images gut verwalten.

Harbor ist die dritte Option: eine selbst gehostete Registry mit Vulnerability Scanning, Replikation und rollenbasierter Zugriffskontrolle. Für Teams unter zehn Entwicklern ist Harbor überdimensioniert, weil allein die Installation 4 GB RAM verbraucht und der Wartungsaufwand für Updates und Backups einer selbst gehosteten Registry regelmäßig unterschätzt wird. Ab 20 Entwicklern und strengen Compliance-Anforderungen (etwa in regulierten Branchen wie Fintech oder Medizintechnik) lohnt sich der Aufwand, weil Harbor dann Features wie Image-Signierung und automatisierte Schwachstellenscans mitbringt, die bei Cloud-Registries zusätzlich kosten.

Meine Empfehlung ist klar: GHCR für GitHub-Teams, GitLab Registry für GitLab-Teams, Harbor nur bei echtem Compliance-Bedarf. Docker Hub als primäre Registry zu nutzen, ergibt 2026 keinen Sinn mehr.

Welche Fehler passieren beim ersten Produktiv-Deployment?

Fehlende Health Checks. Das ist der häufigste Fehler beim Übergang von der Entwicklung in die Produktion. Ohne Health Check weiß der Reverse Proxy nicht, ob ein Container tatsächlich bereit ist, Anfragen zu verarbeiten, obwohl er läuft und Docker ihn als „gesund“ meldet. Datenbankverbindung wird aufgebaut, Caches werden gefüllt, Konfigurationen geladen. Anfragen, die in dieser Startphase eintreffen, scheitern mit Timeouts oder Fehlerseiten, weil die Anwendung noch nicht bereit ist. Ein einfacher HTTP-Endpunkt, der „OK“ zurückgibt, sobald alle Abhängigkeiten initialisiert sind, verhindert das.

Zweiter Klassiker: kein Graceful Shutdown. Wenn ein Container gestoppt wird, sendet Docker das Signal SIGTERM, woraufhin die Anwendung zehn Sekunden Zeit hat (der Standard-Timeout), laufende Anfragen abzuschließen. Viele Frameworks behandeln SIGTERM nicht und beenden sich sofort, weshalb laufende Datenbanktransaktionen abbrechen, WebSocket-Verbindungen reißen und Uploads verloren gehen. Praktisch alle gängigen Webframeworks unterstützen Graceful Shutdown. Es muss nur aktiviert werden.

Dritter Fehler, und der teuerste: Monitoring fehlt. Server läuft, Anwendung antwortet, niemand schaut hin. Unterdessen füllt sich die Festplatte mit Logdateien, ein Container startet unbemerkt dreimal pro Stunde neu, und die Datenbank erreicht ihre Verbindungsgrenzen. Ohne Monitoring merkt das niemand, bis Kunden sich beschweren, weil die Anwendung seit Stunden langsamer wird. Nach dem ersten Ausfall hört man immer den gleichen Satz: „Monitoring steht auf der Liste für nächste Woche.“ Nächste Woche kommt nie.

Vierter Fehler: Secrets in der Compose-Datei. Datenbankpasswörter, API-Keys und Tokens direkt in docker-compose.yml zu schreiben, ist bequem und gefährlich. Compose-Dateien landen im Git-Repository. Ein öffentlich gewordenes Repository bedeutet kompromittierte Zugangsdaten. Separate .env-Dateien, die in .gitignore stehen, sind das Minimum. Besser: Docker Secrets oder ein dedizierter Secret-Manager wie Vault.

Fünfter Fehler: kein Logging-Konzept. Container schreiben ihre Logs auf stdout und stderr, wobei Docker diese standardmäßig als JSON-Dateien speichert, ohne jede Größenbegrenzung. Eine Anwendung, die bei jedem Request eine Logzeile schreibt, produziert auf einem mittelgroßen Server mehrere Gigabyte pro Woche, sodass die Festplatte irgendwann voll ist und alle Container gleichzeitig stoppen. Ein JSON-File-Logging-Driver mit max-size und max-file verhindert das mit zwei Zeilen Konfiguration. Dass so wenige Teams diese zwei Zeilen von Anfang an setzen, erstaunt immer wieder.

Sechster Fehler, der besonders häufig in Multi-Container-Stacks vorkommt: falsche Netzwerk-Konfiguration. Container kommunizieren über interne Docker-Netzwerke miteinander, wobei der Dienstname aus der Compose-Datei als Hostname fungiert. Wer statt „db“ die IP-Adresse des Datenbankcontainers hartcodiert, erlebt nach dem nächsten Neustart eine Überraschung, weil Docker die IP-Adressen bei jedem Start neu vergibt. Genauso problematisch ist es, Container in verschiedene Netzwerke zu legen und sich zu wundern, warum sie sich nicht erreichen.

Der Moment, in dem ein Server nicht mehr reicht

Vertikale Skalierung ist der einfachste Weg: größeren Server mieten. Von 8 GB auf 16 GB RAM, von vier auf acht vCPUs. Bei Hetzner ist das ein Klick im Cloud Panel, obwohl vertikale Skalierung eine harte Grenze hat, weil irgendwann kein größerer Server mehr verfügbar ist oder die Kosten unverhältnismäßig steigen.

Horizontale Skalierung bedeutet: mehrere Server, die sich die Last teilen, während ein Load Balancer eingehende Anfragen verteilt. Bei Hetzner kostet ein Load Balancer 5,39 Euro im Monat. Voraussetzung für horizontale Skalierung ist, dass die Anwendung zustandslos arbeitet, also Sessions in Redis speichert, Dateien auf Object Storage ablegt und keinen lokalen Zustand auf dem Server hält.

Drei Signale, dass der Wechsel auf mehrere Server ansteht. Erstens: Die Verfügbarkeit ist geschäftskritisch und ein einzelner Server stellt ein unakzeptables Ausfallrisiko dar. Zweitens: Die vertikale Skalierung ist ausgereizt oder der nächstgrößere Server wird unverhältnismäßig teuer. Drittens: Deployments verursachen Downtime, weil der einzelne Server während des Updates nicht verfügbar ist. Bei zwei Servern hinter einem Load Balancer lässt sich ein Rolling Deployment fahren: ein Server wird aktualisiert, während der andere weiterhin Anfragen bearbeitet.

Sobald ein zweiter Server ins Spiel kommt, stellt sich die Orchestrierungsfrage, weil Docker Compose nur Container auf einem einzelnen Host verwaltet. Für mehrere Hosts braucht es ein Orchestrierungswerkzeug wie Docker Swarm, Kubernetes oder die leichtgewichtige Variante K3s, die eine eigene Betrachtung verdienen.

Ein Punkt, der in vielen Tutorials unterschlagen wird: Horizontale Skalierung erfordert mehr als nur einen zweiten Server. Session-Management, Dateispeicher und Datenbankverbindungen müssen auf den verteilten Betrieb vorbereitet sein, bevor der erste Load Balancer Traffic verteilt.

Konkret bedeutet das: Sessions wandern in Redis, Dateien auf Object Storage, Datenbank-Verbindungen laufen über einen Connection Pooler wie PgBouncer, der verhindert, dass jeder Container eigene Verbindungen aufbaut und PostgreSQL an sein Limit stößt. Teams, die diese Vorarbeit in der Einzelserver-Phase erledigen, sparen sich beim späteren Übergang zum Cluster Tage an Refactoring-Arbeit.

Ein häufig übersehener Aspekt bei der Skalierung betrifft die Datenbank. PostgreSQL auf zwei Servern zu verteilen, ist grundlegend anders als zwei API-Container hinter einem Load Balancer zu platzieren, weil relationale Datenbanken nicht einfach dupliziert werden können, ohne dass Konflikte bei gleichzeitigen Schreiboperationen entstehen.

Streaming Replication mit einer Primary-Instanz und einer oder mehreren Read Replicas ist der erste Schritt: Schreiboperationen gehen weiterhin an eine einzige Instanz, Leseoperationen werden auf die Replicas verteilt. Für echtes Datenbank-Failover braucht es Werkzeuge wie Patroni oder den CloudNativePG-Operator, die bei ernsthaftem Produktionsbetrieb unerlässlich sind.

Fazit und Ausblick

Vom Laptop in die Produktion führt kein einzelner Sprung, sondern eine Reihe konkreter Entscheidungen, die jeweils vom Kontext abhängen: Einzelserver oder Cluster, Traefik oder Nginx, GitHub Actions oder GitLab CI, GHCR oder Harbor. Teamgröße, Budget und Anforderungen an Verfügbarkeit bestimmen, welche Kombination passt.

Nach meiner Erfahrung ist der Einzelserver für die meisten Teams der richtige Startpunkt, nicht aus Bequemlichkeit, sondern weil die Komplexität eines Clusters erst dann gerechtfertigt ist, wenn der Einzelserver tatsächlich an seine Grenzen stößt. Vier Bausteine verwandeln einen Compose-Stack in ein produktionsfähiges Setup: Traefik als Reverse Proxy, Let’s Encrypt für HTTPS, eine CI/CD-Pipeline für automatische Deployments und GHCR als Image-Registry. Ein Hetzner CX33 für 5,49 Euro im Monat trägt eine erstaunliche Menge Last.

Mein Tipp für den Einstieg: Einen Hetzner CX33 mieten, den bestehenden Compose-Stack mit Traefik und Let’s Encrypt absichern, eine GitHub-Actions-Pipeline aufsetzen und GHCR als Registry nutzen. Das ist an einem Nachmittag erledigt und deckt 90 Prozent der typischen Anforderungen ab.

Sobald Downtime bei Deployments zum Problem wird oder ein einzelner Server das Ausfallrisiko nicht mehr abdeckt, braucht das Team Orchestrierung. Teil 3 vergleicht Docker Swarm, Kubernetes und K3s und zeigt, welches Werkzeug zu welchem Team passt.

Quellenverzeichnis

1. Traefik Labs: Traefik Proxy Documentation, doc.traefik.io/traefik (Stand: Februar 2026)
2. Let’s Encrypt: ACME Protocol Documentation, letsencrypt.org/docs (Stand: Februar 2026)
3. GitHub: GitHub Actions Documentation, docs.github.com/en/actions (Stand: Februar 2026)
4. GitLab: CI/CD Documentation, docs.gitlab.com/ee/ci (Stand: Februar 2026)
5. GitHub: GitHub Container Registry (GHCR) Documentation, docs.github.com/en/packages (Stand: Februar 2026)
6. Heinemeier Hansson, David (DHH): „Why We’re Leaving the Cloud“, 37signals, Oktober 2022
7. Docker Inc.: Docker Compose v2 Release Notes, docs.docker.com/compose/release-notes (Stand: Februar 2026)
8. Docker Inc.: Docker Hub Rate Limiting, docs.docker.com/docker-hub/download-rate-limit (Stand: Februar 2026)
9. cert-manager: Documentation, cert-manager.io/docs (Stand: Februar 2026)
10. Hetzner Online GmbH: Cloud Server Preisliste, hetzner.com/cloud (Stand: Februar 2026, Preiserhöhung ab April 2026 angekündigt)
11. Harbor: Open Source Container Registry, goharbor.io (Stand: Februar 2026)
12. Aqua Security: Trivy Vulnerability Scanner, trivy.dev (Stand: Februar 2026)
13. CAST.AI: „Traefik vs. NGINX: Comparison and Practical Guide“, cast.ai/blog, 2024