Shared Hosting hat seinen Platz. Für eine einfache WordPress-Seite reicht es vollkommen. Für eine gewachsene PHP-Anwendung, die ein Unternehmen operativ am Laufen hält, wird es früher oder später zum Problem. PHP-Version nicht aktualisierbar, kein SSH-Zugang, kein lokaler Dev-Stack, der auch nur annähernd der Produktion entspricht. Ich erkläre, wie ich solche Systeme schrittweise in Container- Umgebungen überführe.

Typische Shared-Hosting-Probleme

Die Symptome sind immer ähnlich: PHP 7.2 oder 7.4, weil der Hoster nichts Neueres anbietet oder der Wechsel nie angegangen wurde. Konfigurationsdateien mit hardcodierten absoluten Pfaden, die auf dem Server stimmen und lokal nie. Eine Datenbankverbindung, die nur mit den Produktionsdaten funktioniert, weil es keine lokale Testumgebung gibt. Und als Konsequenz: jede Änderung direkt live testen.

Schritt 1: Produktionsstand in Docker Compose abbilden

Bevor ich etwas ändere, will ich reproduzieren können, was produktiv läuft. Eine einfache docker-compose.yml für eine typische PHP-Apache-MySQL-Anwendung: 

services:
  web:
    image: php:8.5-apache
    volumes:
      - ./app:/var/www/html
    ports:
      - "8080:80"
    depends_on:
      - db
    environment:
      DB_HOST: db
      DB_NAME: myapp
      DB_USER: myapp
      DB_PASS: secret

  db:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: myapp
      MYSQL_USER: myapp
      MYSQL_PASSWORD: secret
      MYSQL_ROOT_PASSWORD: rootsecret
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

Das Ziel dieser Phase ist nicht Perfektion, sondern Reproduzierbarkeit. Die Anwendung soll lokal starten und die wichtigsten Funktionen zeigen. Dabei fallen oft die ersten Probleme auf: hardcodierte Pfade, fehlende PHP-Extensions, Konfigurationswerte, die direkt im Code stehen.

Schritt 2: Anwendung containerisierbar machen

Hardcodierte Pfade wie /var/www/vhosts/meinedomain.de/httpdocs/config.php müssen weg. Konfiguration gehört in Umgebungsvariablen. Das betrifft Datenbankverbindung, externe API-Keys, Pfade zu Upload-Verzeichnissen. Kein langer Refactor – nur die wenigen Stellen, die den Start des Containers verhindern.

PHP-Extensions, die auf dem Shared Hosting vorhanden waren, müssen im Dockerfile explizit installiert werden. Das macht sichtbar, was die Anwendung tatsächlich voraussetzt – häufig wurde das nie dokumentiert.

Schritt 3: Deployment auf VPS oder managed Hosting

Für kleine Betriebe ist ein einfacher VPS ab etwa 10 Euro pro Monat eine realistische Alternative. Hetzner, DigitalOcean, netcup – auf einem solchen Server lässt sich Docker Compose direkt betreiben. Kein Kubernetes, kein komplexes Orchestrierungs-Setup. Einfach docker compose up -d und ein Reverse Proxy wie Traefik oder Nginx davor.

Managed Container-Hosting wie Railway, Render oder Fly.io ist etwas teurer, nimmt aber die Server-Administration komplett ab – für Betriebe ohne eigene IT-Abteilung oft die sinnvollere Wahl.

Ein Kunde hat für sein Shared-Hosting-Paket mit Datenbank 35 Euro pro Monat gezahlt – und dafür PHP 7.4 bekommen, das seit 2022 keine Sicherheits-Updates mehr erhält. Ein VPS mit Docker, aktueller PHP-Version und vollständiger Kontrolle kostet 10 Euro. Die Rechnung ist einfach.

Fazit

Die Migration von Shared Hosting zu Container ist kein Wochenprojekt, wenn man schrittweise vorgeht. Der entscheidende erste Schritt ist, die Produktionsumgebung lokal reproduzierbar zu machen. Alles weitere – saubere Konfiguration, automatisiertes Deployment, aktuelle PHP-Version – ergibt sich daraus fast von selbst.