Zum Hauptinhalt springen

Deployment-Anleitungen

Es gibt mehr als einen Weg, eine Anwendung auf die mittwald Cloud-Plattform zu bringen. Diese Seite gibt dir einen Überblick über die verfügbaren Strategien und hilft dir dabei, die passende für dein Projekt auszuwählen.

Zwei Laufzeitmodelle​

Der größte Teil der Entscheidung ergibt sich aus einer einzigen Frage: Soll deine Anwendung in einer Managed-Umgebung oder als Container laufen?

  • Managed-Umgebungen (in Form einer eigenen PHP- oder Node.js-App) laufen in einem Webspace, auf einer Laufzeitumgebung, die von mittwald bereitgestellt und gepflegt wird (PHP, Node.js oder statische Dateien). Du deployst Quellcode, in der Regel über SSH, und die Plattform kümmert sich um Webserver, Sprachlaufzeit, TLS-Zertifikate und Ähnliches. Das ist das klassische Modell für PHP-Anwendungen wie TYPO3, Shopware oder WordPress.
  • Container führen ein Docker-Image aus, das du selbst baust. Du kontrollierst die komplette Laufzeitumgebung. Das ist die richtige Wahl für alles, was die Managed Runtimes nicht abdecken, oder wenn du reproduzierbare Builds möchtest. Die zugrundeliegenden Konzepte findest du unter Container.

Wenn du dir unsicher bist, wie das zusammenhängt, wirf einen Blick auf den Plattform-Überblick.

Welche Strategie sollte ich verwenden?​

Deine SituationEmpfohlene Strategie
Du hast Quellcode in Git, kein Dockerfile, und willst schnell einen laufenden ServiceZero-Conf-Deployment
Du hast eine App mit einem KI-Tool gebaut (Replit, Lovable, Cursor) und willst sie live sehenZero-Conf-Deployment plus die plattformspezifischen Hinweise
Du baust bereits ein Docker-Image und pflegst eine stack.yamlmittwald/deploy-container-action
Du deployst eine PHP/Composer-Anwendung in ein Managed HostingDeployer
Du deployst ein TYPO3- oder Neos-Projekt und nutzt bereits SurfTYPO3 Surf
Du möchtest Projekte, Apps, Datenbanken und Domains als Code verwaltenTerraform

Die Strategien im Detail​

Zero-Conf-Container-Deployment​

Verwende es, wenn: du mit möglichst wenig Konfiguration von einem Git-Repository zu einer laufenden Anwendung kommen willst, ohne ein Dockerfile oder eine Stack-Definition zu schreiben.

Das Zero-Conf-Deployment analysiert deinen Quellcode, leitet daraus ab, wie er gebaut und gestartet wird, und deployt das Ergebnis in das Container-Hosting. Du kannst es manuell von deinem Rechner aus ausführen:

user@local $ mw project create --description=my-project --update-context
user@local $ mw experimental deploy

Sobald das funktioniert, kannst du es mit der mittwald/zerodeploy-action automatisieren, die denselben Build bei jedem Push ausführt.

Abwägung: Komfort vor Kontrolle. Das Build-Verhalten wird abgeleitet, deshalb brauchen ungewöhnliche Projektstrukturen (Monorepos, exotische Paketmanager) unter Umständen ein paar Umgebungsvariablen, um den Build in die richtige Richtung zu lenken.

Was du als Nächstes lesen kannst:

Container-Deployment mit expliziter Stack-Definition​

Verwende es, wenn: dein Team den Build bereits selbst verantwortet. Du hast ein Dockerfile, pushst Images in eine Registry und willst Services, Ports und Volumes selbst beschreiben.

Ein GitHub-Actions-Workflow baut das Image, pusht es und übergibt anschließend deine Stack-Definition an mStudio. Du behältst die volle Kontrolle darüber, welche Services bei einem Rollout neu erstellt werden, und kannst denselben Stack in mehrere Umgebungen deployen.

Abwägung: mehr bewegliche Teile, die gepflegt werden wollen, dafür ist nichts an der Laufzeitumgebung implizit.

Weiterlesen: Deployment von containerisierten Anwendungen mit GitHub Actions

Deployer​

Verwende es, wenn: du eine PHP-Anwendung in eine Managed App deployst und atomare Releases möchtest, die sich zurückrollen lassen.

Deployer kopiert jedes Release in ein eigenes Verzeichnis und schwenkt anschließend einen current-Symlink um. Damit ist ein Deployment atomar und umkehrbar. Das mittwald-Recipe übernimmt zusätzlich das Anlegen des SSH-Users, das Verknüpfen von Domains, die Installation von Laufzeitabhängigkeiten und das Leeren des OPcache.

Abwägung: Der Ansatz ist PHP-lastig und benötigt SSH-Zugriff. Dafür ist er der ausgereifteste Weg für klassisches PHP-Hosting und lässt sich sowohl in GitHub Actions als auch in GitLab CI einbinden.

Weiterlesen: PHP-Anwendungen mit Deployer deployen

TYPO3 Surf​

Verwende es, wenn: du TYPO3 oder Neos deployst und dein Projekt bereits Surf nutzt.

Surf erfüllt denselben Zweck wie Deployer, mit Werkzeugen, die speziell auf TYPO3 und Neos zugeschnitten sind. Wenn du neu anfängst und keine starke Präferenz hast, bietet Deployer die tiefere mittwald-Integration.

Weiterlesen: PHP-Anwendungen mit TYPO3 Surf deployen

Terraform​

Verwende es, wenn: du deine Infrastruktur (Projekte, Apps, Datenbanken, Domains, Container) als Code beschreiben und über Umgebungen hinweg reproduzierbar machen willst.

Terraform ergänzt die oben genannten Strategien, statt sie zu ersetzen: Es stellt die Ressourcen bereit und verwaltet sie, in denen deine Anwendung läuft, und du kannst es mit jeder der Deployment-Methoden für den Anwendungscode kombinieren. Außerdem kannst du mittwald-Ressourcen zusammen mit denen anderer Anbieter, etwa DNS oder Monitoring, in einer einzigen Konfiguration verwalten.

Weiterlesen: Infrastructure as Code mit Terraform

Was du in jedem Fall brauchst​

  • Ein mStudio-API-Token für alles, was mit der mittwald-API spricht; siehe API-Token erhalten.
  • Die mittwald CLI (mw) für die meisten manuellen Schritte; siehe die CLI-Dokumentation.
  • Ein Git-Repository, denn alle hier beschriebenen Strategien deployen aus der Versionsverwaltung.

Wie geht es weiter​