Container Hosting Reverse Proxy: SSL & HTTPS inklusive

Wer eigene Anwendungen in Containern betreibt, kennt das Muster: Neben WordPress, n8n oder der eigenen Web-Anwendung läuft fast immer ein zusätzlicher Container für nginx, Traefik oder Caddy. Dazu kommt ein Mechanismus für die SSL-Zertifikate, der regelmäßig erneuern muss. Dieser Unterbau kostet Arbeitsspeicher, Zeit und Aufmerksamkeit - und er ist eine häufige Fehlerquelle, wenn ein Zertifikat nachts abläuft.

Im Container-Hosting von SpeedIT Solutions ist dieser Teil bereits erledigt. Vor allen Projekten steht ein zentraler Reverse Proxy, den wir betreiben, überwachen und aktuell halten. In diesem Beitrag erklären wir, was er für Sie übernimmt, was Sie sich dadurch sparen und in welchen Fällen ein eigener Webserver-Container trotzdem sinnvoll ist.

Was ist ein Reverse Proxy?

Ein Reverse Proxy nimmt Anfragen aus dem Internet entgegen und leitet sie an die passende Anwendung weiter. Für Besucher sieht es so aus, als käme die Antwort direkt von Ihrer Website. Tatsächlich spricht der Browser aber nur mit dem Proxy: Er stellt die verschlüsselte Verbindung her, prüft, ob der Zugriff erlaubt ist, und reicht die Anfrage dann an Ihren Container weiter.

Ihr Container muss dafür nur eines können: auf einem Port HTTP sprechen. Ob das Port 80 bei WordPress ist, 5678 bei n8n oder 3000 bei Ihrer Node.js-Anwendung, spielt keine Rolle. Den Rest erledigt die Plattform.

Das übernimmt unser Reverse Proxy für Sie

SSL-Zertifikate automatisch: Für jede Web-Adresse stellen wir ein Zertifikat von Let's Encrypt aus und erneuern es rechtzeitig vor Ablauf. Sie müssen weder Certbot einrichten noch an Verlängerungen denken.
HTTPS erzwungen: Aufrufe über HTTP werden automatisch auf HTTPS umgeleitet. Zusätzlich senden wir HSTS, damit Browser Ihre Adresse künftig nur noch verschlüsselt aufrufen.
Moderne Übertragung: HTTP/2 und Kompression mit zstd und gzip sind aktiv. Texte, Skripte und Stylesheets kommen dadurch spürbar kleiner beim Besucher an.
WebSockets: Live-Verbindungen, wie sie Chat-Werkzeuge, Dashboards oder n8n nutzen, werden ohne zusätzliche Einstellung durchgereicht.
Echte Besucher-IP: Ihre Anwendung erhält die Adresse des Besuchers in den üblichen Kopfzeilen wie X-Forwarded-For. Statistiken, Sperrlisten und Protokolle in Ihrer Anwendung funktionieren damit wie gewohnt.
Weniger Angriffsfläche: Der Proxy blendet die Server-Kennung aus und setzt Sicherheits-Kopfzeilen wie X-Content-Type-Options. Ihr Container ist von außen nicht direkt erreichbar, sondern nur über den Proxy.
Zugriffsschutz je Adresse: Auf Wunsch geben Sie eine Web-Adresse nur für bestimmte IP-Adressen frei, etwa Ihr Büro oder Ihr VPN, schützen sie mit Benutzername und Passwort oder kombinieren beides. Ideal für Admin-Oberflächen, Staging-Umgebungen und interne Werkzeuge.
Uploadgröße einstellbar: Wie groß hochgeladene Dateien sein dürfen, legen Sie je Adresse selbst fest.
Datenschutz: Die Zugriffsprotokolle des Proxys mit IP-Adressen bewahren wir höchstens sieben Tage auf. Danach werden sie automatisch gelöscht.

Ihr Container braucht nur einen Port

Sie veröffentlichen keinen Port 80 oder 443 und hinterlegen keine Zertifikate im Container. Sie nennen im Kundenbereich nur den Port, auf dem Ihre Anwendung lauscht. Die Web-Adresse mit SSL-Zertifikat steht kurz darauf bereit, eine Prüfkette zeigt, ob Adresse, Zertifikat, Container und Anwendung zusammenspielen. Wie das im Einzelnen geht, zeigt die Anleitung Container im Web erreichbar machen.

Was Sie sich sparen

Ohne vorgeschalteten Proxy besteht selbst eine kleine WordPress-Installation schnell aus drei oder vier Containern: Anwendung, Datenbank, Webserver als Proxy und ein Helfer für die Zertifikate. Bei uns genügen zwei. Das hat ganz praktische Vorteile:

Mehr Ressourcen für Ihre Anwendung: Der Arbeitsspeicher, den ein Proxy-Container belegen würde, steht Ihrer Anwendung zur Verfügung.
Weniger Pflege: Sicherheitsupdates für den Proxy spielen wir ein. Sie kümmern sich nur um Ihre eigene Software.
Weniger Fehlerquellen: Keine abgelaufenen Zertifikate, keine falsch gesetzten Labels, keine Konflikte um Port 443.
Einfacher Umzug: Eine vorhandene docker-compose-Datei übernehmen Sie, ohne den Proxy-Teil nachbauen zu müssen.

So sieht eine typische docker-compose-Datei für WordPress mit Datenbank aus, wie Sie sie direkt aus docker-compose importieren können. Einen Proxy-Container und Zertifikate enthält sie nicht mehr. Den Port 80 von WordPress übernimmt der Import als Vorschlag für die Web-Adresse, die Datenbank liegt in einem internen Netz ohne Weg ins Internet.

YAML docker-compose.yml

services:
  wordpress:
    image: wordpress:6
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: datenbank
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORT}
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp-daten:/var/www/html
    networks: [web, intern]

  datenbank:
    image: mariadb:11
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: ${DB_PASSWORT}
      MARIADB_RANDOM_ROOT_PASSWORD: "1"
    volumes:
      - db-daten:/var/lib/mysql
    networks: [intern]

networks:
  web: {}
  intern:
    internal: true

volumes:
  wp-daten: {}
  db-daten: {}

Eigene Images und private Registries

Nicht jede Anwendung kommt aus einem öffentlichen Verzeichnis. Eigene Web-Anwendungen, interne Werkzeuge oder angepasste Varianten bekannter Software liegen meist in einer privaten Registry, etwa in der GitLab Container Registry, bei GitHub Packages oder in einem eigenen Harbor. Auch solche Registries binden Sie im Container-Hosting an - mit Anmeldung.

Einmal anbinden: Sie tragen die Adresse Ihrer Registry ein, zum Beispiel registry.muster.de/team, und bei Bedarf Benutzername und Passwort oder einen Token.
Freigabe durch unser Team: Wir prüfen die Anbindung einmalig und geben sie frei, Sie erhalten eine E-Mail. Danach nutzen Sie jedes Image aus dieser Registry mit seiner vollständigen Adresse, etwa registry.muster.de/team/shop-api:2.3.
Zugangsdaten geschützt: Wir speichern sie verschlüsselt und verwenden sie ausschließlich für Ihre eigenen Projekte, nie für andere Kunden. Ändern oder entfernen können Sie sie jederzeit im Kundenbereich.
Jede Version geprüft: Auch Images aus Ihrer eigenen Registry durchlaufen vor dem Start die Sicherheitsprüfung auf bekannte Schwachstellen. Für ein Update wählen Sie einfach die neue Version.

docker-compose mit eigenen Images

Beim Import einer docker-compose-Datei dürfen Dienste auf Images aus Ihrer angebundenen Registry verweisen. Der Import erkennt die freigegebene Registry und nutzt die hinterlegten Zugangsdaten automatisch - Passwörter gehören also nicht in die Datei. Images aus den offiziellen Quellen wie Docker Hub oder GitHub lassen sich dabei beliebig mit Ihren eigenen kombinieren. Dienste, die mit build erst aus Quelltext gebaut werden, bauen Sie vorher selbst, zum Beispiel in Ihrer CI-Pipeline, und laden das fertige Image in Ihre Registry.

So kann eine Datei mit eigener Anwendung und offiziellem Cache aussehen. Wie Sie eine Registry anbinden, zeigt die Anleitung Container anlegen.

YAML docker-compose.yml

services:
  api:
    image: registry.muster.de/team/shop-api:2.3
    ports:
      - "3000:3000"
    environment:
      CACHE_HOST: cache
    networks: [web, intern]

  cache:
    image: valkey/valkey:8
    networks: [intern]

networks:
  web: {}
  intern:
    internal: true

Token nur mit Leserechten

Legen Sie für die Anbindung einen eigenen Token an, der Images nur lesen darf - bei GitLab zum Beispiel einen Deploy-Token mit dem Recht read_registry, bei GitHub einen Token mit read:packages. So bleibt der Zugriff auf das Nötigste beschränkt, und Sie können ihn jederzeit widerrufen, ohne Ihr persönliches Konto anzufassen.

Wann ein eigener Webserver-Container trotzdem sinnvoll ist

Für die meisten Anwendungen reicht der zentrale Proxy völlig aus. Es gibt aber Fälle, in denen Sie zusätzlich einen eigenen Webserver wie nginx oder Apache in einem Container betreiben sollten:

PHP-FPM-Images: Varianten wie wordpress:fpm oder nextcloud:fpm enthalten keinen Webserver, sondern nur PHP. Sie brauchen davor einen Webserver-Container, der die Anfragen an PHP übergibt. Einfacher sind die Varianten mit eingebautem Webserver, etwa wordpress mit Apache.
Eigene Umleitungs- und Rewrite-Regeln: Wenn Sie umfangreiche Weiterleitungen, Umschreibungen oder besondere Kopfzeilen brauchen, die Ihre Anwendung nicht selbst setzen kann.
Mehrere Dienste unter einer Domain: Sollen etwa /api und /app unter derselben Adresse zu verschiedenen Containern führen, verteilt ein eigener Webserver die Pfade.
Zwischenspeicher und statische Dateien: Für eigenes Caching oder das Ausliefern großer statischer Dateien neben der Anwendung.
Besondere Anforderungen an die Verbindung: Etwa Client-Zertifikate oder eigene TLS-Einstellungen. Solche Dienste veröffentlichen Sie über einen eigenen TCP-Port statt über die Web-Adresse.

Auch dann gilt: Ihr Webserver-Container sitzt hinter unserem Proxy. Um Zertifikate, HTTPS-Weiterleitung und Zugriffsschutz müssen Sie sich weiterhin nicht kümmern - Ihr Webserver spricht intern einfach HTTP.

Eigene Domain in wenigen Schritten

Jeder Container mit Web-Adresse erhält zunächst eine Adresse unter unserer Plattform-Domain. Ihre eigene Domain verbinden Sie im Kundenbereich: Domain eintragen, beim Anbieter einen CNAME- oder A-Eintrag anlegen, auf „DNS prüfen" klicken. Sobald der Eintrag stimmt, stellen wir das Zertifikat automatisch aus. Eine Domain wird erst eingerichtet, wenn der DNS-Eintrag nachweist, dass sie zu Ihrem Projekt gehört. So kann niemand Ihre Domain auf ein fremdes Projekt lenken.

Sicherheit hinter dem Proxy: die Plattform

Der Proxy ist nur die erste Schicht. Dahinter ist das Container-Hosting so aufgebaut, dass Projekte sauber voneinander getrennt sind und Sie jederzeit sehen, was passiert:

Rootless Podman: Container laufen ohne Root-Rechte. Jedes Projekt hat einen eigenen Linux-Benutzer, feste Grenzen für Arbeitsspeicher, CPU, Speicher und Prozesse sowie einen eigenen Speicherbereich mit Kontingent auf schnellem NVMe-Speicher.
Geprüfte Images: Jede Image-Version wird vor dem Start auf bekannte Schwachstellen geprüft. Kritische Funde sehen Sie vor dem Start und entscheiden bewusst.
Netze und Firewall: Interne Netze haben keinen Weg ins Internet - ideal für Datenbanken. Ausgehende Verbindungen erlauben Sie ganz oder nur zu bestimmten Zielen. Mehr dazu unter Netze und Firewall.
Nächtliche Prüfung: Ihre Volumes werden jede Nacht auf Schadsoftware und bekannte Hintertüren geprüft, Funde melden wir Ihnen per E-Mail und im Kundenbereich.
Snapshots und Backups: Snapshots bringen Sie nach einem misslungenen Update in Sekunden zurück, die Backup-Option sichert Ihre Daten jede Nacht verschlüsselt in einem getrennten Rechenzentrum (Backup und Snapshot).
Standort Deutschland: Betrieb in Deutschland und DSGVO-konform, mit Zwei-Faktor-Anmeldung im Kundenbereich und persönlichem Support.

Einen Überblick über alle Schutzmaßnahmen finden Sie im Artikel Sicherheit im Container-Hosting.

Häufige Fragen

Brauche ich für mein Container-Hosting ein eigenes SSL-Zertifikat?

Nein. Für jede Web-Adresse, auch für Ihre eigene Domain, stellen wir automatisch ein Zertifikat aus und erneuern es rechtzeitig. Sie müssen nichts hochladen und nichts verlängern.

Kann ich weiterhin nginx, Traefik oder Caddy in meinem Projekt nutzen?

Ja. Wenn Sie besondere Regeln oder ein Pfad-Routing brauchen, betreiben Sie Ihren Webserver als ganz normalen Container. Er sitzt dann hinter unserem Proxy und spricht intern HTTP - um Zertifikate kümmern Sie sich auch in diesem Fall nicht.

Meine Anwendung spricht nur HTTPS. Funktioniert das?

Ja. Schalten Sie bei der Web-Adresse die Einstellung „Container spricht HTTPS" ein. Der Proxy verbindet sich dann verschlüsselt mit Ihrem Container.

Sieht meine Anwendung die echte IP-Adresse der Besucher?

Ja. Der Proxy übergibt die Adresse des Besuchers in den üblichen Kopfzeilen wie X-Forwarded-For. Viele Anwendungen werten diese automatisch aus, bei manchen stellen Sie den Proxy als vertrauenswürdig ein.

Kann ich eine Admin-Oberfläche nur für mein Büro freigeben?

Ja. Je Web-Adresse legen Sie fest, ob sie öffentlich ist, nur für bestimmte IP-Adressen oder Netze erreichbar ist, mit Passwort geschützt wird oder beides kombiniert.

Kann ich Images aus meiner privaten Registry nutzen, auch mit Anmeldung?

Ja. Binden Sie Ihre Registry, etwa GitLab, GitHub Packages oder Harbor, mit Benutzername und Passwort oder Token im Kundenbereich an. Nach unserer einmaligen Freigabe nutzen Sie die Images direkt im Assistenten und beim Import aus docker-compose. Die Zugangsdaten speichern wir verschlüsselt und nur für Ihre Projekte.

Was ist mit Diensten, die kein HTTP sprechen?

Für Datenbanken, Spieleserver oder andere Protokolle veröffentlichen Sie einen eigenen TCP- oder UDP-Port. Wer diesen Port erreichen darf, legen Sie in der Firewall des Projekts fest.

Fazit

Ein vorgeschalteter Reverse Proxy nimmt Ihnen beim Container-Hosting die lästigste Arbeit ab: Zertifikate, HTTPS, Kompression und Zugriffsschutz laufen einfach mit. Ihre Container konzentrieren sich auf die Anwendung, Ihre Ressourcen fließen in das, was Ihren Besuchern nützt. Einen eigenen Webserver-Container brauchen Sie nur noch, wenn Sie wirklich erweiterte Regeln oder Konfigurationen benötigen - und selbst dann bleibt die Verschlüsselung Sache der Plattform.

Container-Hosting

Eigene Container, ohne Server-Pflege

Sie wählen Ressourcen und Software, wir stellen die Plattform: Reverse Proxy mit SSL, Netze, Firewall, Snapshots und Backups - gehostet in Deutschland.

Container-Hosting ansehen Web-Adresse einrichten