PHP auf Nodion deployen

PHP Schritt für Schritt deployen

1. composer.json anlegen und composer.lock committen Nodion erkennt PHP an der composer.json. Ein Repository mit nur einer index.php wird nicht erkannt; hast du noch keine composer.json, reicht eine kleine wie diese. Der Build führt composer install --no-dev --optimize-autoloader aus, alles, was die App zur Laufzeit braucht, gehört also in require, nicht in require-dev. Committe die composer.lock, dann installiert der Build genau die Versionen, die du getestet hast. composer.json

   {
     "require": {
       "php": "8.4.*"
     }
   }

2. Öffentliche Dateien in public/ ablegen FrankenPHP nutzt public/ als Document Root. Gibt es das Verzeichnis nicht, nimmt Nodion web/, und fehlen beide, das Wurzelverzeichnis des Repositorys. Leg index.php und deine Assets in public/ und lass vendor/, Konfiguration und Quellcode daneben liegen, damit nur ausgeliefert wird, was ins Web gehört.

   composer.json
   composer.lock
   src/
   public/
     index.php

3. Webserver wählen FrankenPHP ist der Standard und braucht keine Einrichtung. Für php-fpm hinter nginx oder Apache httpd legst du auf dem Tab Environment BP_PHP_SERVER mit dem Wert nginx oder apache an und setzt das Häkchen Build. Apache liest dann auch deine .htaccess-Dateien. Jeder andere Wert lässt den Build scheitern.
4. App anlegen und Datenbank anhängen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an, wähle Branch und Region EU Central und lass die Build-Strategie auf Buildpacks. Dann legst du eine MySQL- oder PostgreSQL-Datenbank in derselben Region an und hängst sie auf dem Tab Environment an: Die App bekommt beim nächsten Deploy DATABASE_URL, und zwar nur zur Laufzeit. Passwörter und API-Keys markierst du als Secret.
5. Migrationen bei jedem Deploy ausführen Eine release:-Zeile in einer Procfile läuft bei jedem Build einmal, nach dem Build und bevor die neue Version startet. Scheitert sie, stoppt der Deploy und die laufende Version bleibt live. Das Migrations-Tool, etwa Doctrine Migrations oder Phinx, gehört in require. Procfile

   release: vendor/bin/doctrine-migrations migrate --no-interaction

Gut zu wissen

• PHP-Version pinnenNodion liest zuerst .php-version, dann require.php aus der composer.json; ohne beides bekommst du PHP 8.3. Ein Bereich nimmt das neueste passende Release, "^8.2" landet also bei PHP 8.5. Willst du auf einer Version bleiben, schreib 8.3 in die .php-version oder verlange "8.3.*".
• SymfonyNodion erkennt Symfony an bin/console plus symfony.lock, führt im Build bin/console cache:warmup --env=prod aus und setzt zur Laufzeit APP_ENV=prod und APP_DEBUG=0. Leg APP_ENV=prod zusätzlich mit dem Häkchen Build an, damit die Composer-Skripte während der Installation nicht mit dev aus deiner .env laufen. asset-map:compile führt Nodion nicht aus; mit AssetMapper ergänzt du es in den auto-scripts der composer.json. Für Builds mit Encore oder Vite nimmst du ein Dockerfile.
• WorkerFür einen Queue-Worker ergänzt du die Procfile um eine Zeile wie worker: php bin/worker.php und eine ausdrückliche web:-Zeile, denn ohne sie wird der erste Procfile-Eintrag außer release: zum Standardbefehl. Den Standard-Startbefehl zeigt das Build-Log; für FrankenPHP passt web: frankenphp php-server --listen :$PORT --root public/. Dann legst du auf dem Tab Processes einen Prozess worker ohne Port an.
• Health-Check-PfadDer Traffic wechselt auf ein neues Release, sobald / mit 2xx oder 3xx antwortet. Antwortet / mit 401 oder 404, trag in den App-Einstellungen einen Health-Check-Pfad ein, der 200 liefert.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.
• Cloud Native Buildpacks erklärt Buildpacks machen aus deinem Quellcode ein Container-Image ohne Dockerfile. Was sie sind und wie sie funktionieren.

PHP auf Nodion: Fragen und Antworten