Site-Einstellungen: PHP-Version, Web-Verzeichnis, Isolation

Die Seite Einstellungen einer Site legt fest, wie die Site auf ihrem Server läuft: ihre PHP-Version, das Verzeichnis, das Nginx ausliefert, ob Deployments Zero-Downtime-Releases nutzen und ob die Site isoliert läuft. Außerdem findest du hier die Zugangsdaten für private Composer- und npm-Pakete und legst fest, wohin die Deploy-Ergebnisse einer Site gehen. Hier klonst oder löschst du auch eine Site.

Du findest sie ganz unten in der Seitenleiste der Site unter Einstellungen. Einiges stellst du an anderer Stelle ein: die Domain unter Domains und SSL, Repository und Branch unter Deployments und das Verzeichnis sowie das Monorepo-Root einmalig beim Anlegen der Site.

Oben auf der Seite gibt es Tabs:

WordPress, phpMyAdmin und Sites auf einem Load Balancer haben kein Repository und keinen Build. Sie haben deshalb nur die allgemeinen Einstellungen und keine Tabs.

Wo die Site auf dem Server liegt#

Jede Site hat ein Verzeichnis im Home-Ordner des Benutzers, unter dem sie läuft, aufgebaut für Zero-Downtime-Deployments:

/home/vimonto/example.com/
├── current -> releases/20261007143000   # the live release
├── releases/                            # one directory per deploy
└── shared/
    ├── .env                             # kept across releases
    └── storage/                         # Laravel's storage, kept across releases

Die Übersicht der Site zeigt Adresse, Verzeichnis, Web-Root, HTTPS, Repository, Branch, Quick Deploy und die letzten Deploys auf einen Blick. Bei einer lastverteilten Site listet sie stattdessen die App-Server dahinter auf. Darunter zeigt der Bereich Uptime, ob die Site erreichbar ist, mit 90 Tagen Verlauf (siehe Uptime-Monitoring). Rechts listet Aktivität die letzten Arbeiten an der Site auf, die neuesten zuerst: Deploys, Zertifikate, Worker, Funktionen, Befehle und andere Aufgaben, jeweils mit wer sie gestartet hat und wie sie ausgegangen sind. Klicke auf eine Zeile, um die Aufgabe mit ihrer Ausgabe zu öffnen; Mehr laden zeigt ältere.

Bis die Site ganz eingerichtet ist, beginnt die Übersicht mit Nächste Schritte, etwa ein Repository verbinden oder HTTPS einschalten. Ein Schritt, den du nicht brauchst, bliebe sonst immer offen: Klicke auf Verstecken, um die Liste für diese Site auszublenden. Das gilt nur für dich.

Eine Site auf einem Load Balancer leitet Anfragen nur an ihre App-Server weiter, deshalb hat ihre Seite Einstellungen keine PHP-Version, kein Web-Verzeichnis, keine Zero-Downtime-Deploys und keine Isolation: Dort steht, dass es nichts einzustellen gibt, mit einem Link auf ihre Seite Lastverteilung, wo du sie verwaltest. Site löschen gibt es dort wie bei jeder Site.

Die PHP-Version ändern#

Bei PHP- und Laravel-Sites listet PHP-Version die auf dem Server installierten Versionen auf. Wähle eine aus und klicke auf Speichern.

Vimonto Deploy schreibt die Nginx-Konfiguration der Site neu, damit PHP-Anfragen an PHP-FPM der neuen Version gehen, und verschiebt bei einer isolierten Site deren PHP-FPM-Pool auf diese Version. Willst du eine Version nutzen, die nicht aufgelistet ist, installiere sie zuerst auf der Seite PHP des Servers.

Prüfe außerdem, dass dein Deploy-Skript kein festes PHP-Binary wie php8.3 aufruft.

Das Web-Verzeichnis ändern#

Das Web-Verzeichnis ist das Verzeichnis in deinem Projekt, das Nginx ausliefert: /public bei Laravel, oft /dist oder /build bei einer statischen Site oder / für das Projekt-Root. Es ist relativ zum Release (oder zum Root-Verzeichnis des Monorepos, falls die Site eines hat). Verwende Buchstaben, Ziffern, Punkte, Bindestriche und Unterstriche, zum Beispiel /public oder /apps/web/public.

Klicke auf Speichern, und die Nginx-Konfiguration wird mit dem neuen root neu geschrieben.

Den Port einer Node.js-App ändern#

Bei einer Node.js-Site ersetzt Port deiner App das Web-Verzeichnis. Nginx leitet jede Anfrage an deine App auf 127.0.0.1 und diesen Port weiter, zwischen 1024 und 65535. Speicherst du einen neuen Port, zieht der Prozess, der deine App betreibt (unter Prozesse), mit um und startet neu. Hast du selbst einen Startbefehl hinzugefügt, passe den Port darin selbst an.

Zero-Downtime-Deploys#

Mit eingeschalteten Zero-Downtime-Deploys (Standard) baut jedes Deployment ein neues Release in releases/ und schaltet es erst live, wenn alles geklappt hat, indem der Symlink current in einem Schritt umgestellt wird. Besucher sehen nie einen halbfertigen Build, ein fehlgeschlagener Build ändert nichts, alte Releases werden aufgeräumt, und du kannst auf ein früheres Release zurückrollen.

Ist die Option aus, wird der Code direkt vor Ort aktualisiert: Jedes Deployment aktualisiert und baut dasselbe Release, releases/live. Das ist schneller und braucht weniger Speicherplatz, aber Besucher bekommen den Build mit, ein fehlgeschlagener Build kann die Live-Site halb aktualisiert zurücklassen, und es gibt nichts, auf das du zurückrollen kannst.

Die Änderung gilt ab dem nächsten Deployment. Siehe Deployments.

Bei installierten Anwendungen wie WordPress und phpMyAdmin wird der Schalter nicht angezeigt.

Website-Isolation#

Website-Isolation zeigt, ob die Site unter einem eigenen Linux-Benutzer läuft. Du wählst sie beim Anlegen der Site; danach lässt sie sich nicht mehr ändern.

Isolation trennt die Sites auf demselben Server voneinander: Ein verwundbares Plugin in einer Site kann weder die Dateien noch die .env einer anderen lesen. Nginx kann die Dateien der Site trotzdem lesen, weil der Systembenutzer, unter dem Nginx läuft, zur Gruppe des Site-Benutzers hinzugefügt wird.

Nutze Isolation, wenn ein Server Sites für verschiedene Kunden hostet oder Sites, denen du weniger vertraust, etwa WordPress.

Zugangsdaten für Composer und npm#

Um bei einem Deploy private Pakete zu installieren, etwa Laravel Nova, Private Packagist oder Pakete aus GitHub Packages, braucht der Build Zugangsdaten. Du verwaltest sie in den Tabs Composer und npm. Es sind dieselben Zugangsdaten, die du beim Anlegen der Site unter Composer-Authentifizierung und npm-Authentifizierung eintragen kannst.

Composer-Zugangsdaten hinzufügen#

1. Öffne die Einstellungen der Site und klicke auf den Tab Composer (Authentifizierung für Composer-Pakete).
2. Klicke auf Zugangsdaten hinzufügen.
3. Trage den Host ein (zum Beispiel repo.packagist.com oder nova.laravel.com), den Benutzername und das Passwort. Ein Token oder Lizenzschlüssel gehört ebenfalls in Passwort.
4. Klicke auf Speichern.

Das sind die http-basic-Zugangsdaten aus Composers auth.json. Du kannst einen Eintrag pro Host hinzufügen, höchstens 10.

npm-Zugangsdaten hinzufügen#

1. Klicke auf den Tab npm (Authentifizierung für npm-Pakete).
2. Klicke auf Zugangsdaten hinzufügen.
3. Trage die Registry ein, eine https://-Adresse wie https://npm.pkg.github.com oder https://registry.npmjs.org, und das Token.
4. Klicke auf Speichern.

Ein Eintrag pro Registry, höchstens 10.

Zugangsdaten ändern oder entfernen#

Die Liste zeigt den Host oder die Registry (und den Benutzernamen), aber nie wieder das Passwort oder Token: Dort steht ••••••••. Klicke auf Bearbeiten, um einen Eintrag zu ändern; lässt du Passwort oder Token leer, bleibt der gespeicherte Wert erhalten. Klicke auf Entfernen und bestätige, um ihn zu löschen; der nächste Deploy kann dann keine privaten Pakete mehr von dort installieren.

Wie werden die Zugangsdaten verwendet?#

Die Zugangsdaten werden verschlüsselt in Vimonto Deploy gespeichert und nur während eines Deploys an den Build übergeben: Composer bekommt sie über die Umgebungsvariable COMPOSER_AUTH, der Paketmanager über eine temporäre npm-Benutzerkonfiguration (NPM_CONFIG_USERCONFIG), die danach gelöscht wird. Auf dem Server wird nichts gespeichert, es liegt also keine auth.json oder .npmrc in deinem Home-Verzeichnis oder Release. Änderungen gelten ab dem nächsten Deploy.

Den Tab Composer gibt es für Laravel-, Symfony-, Statamic- und PHP-Sites, den Tab npm für jede Site mit Repository.

Deploy-Benachrichtigungen#

Jedes Mitglied erfährt schon über die Glocke und seine eigenen Benachrichtigungseinstellungen von Deploys. Im Tab Benachrichtigungen schickst du die Deploy-Ergebnisse einer Site an weitere Stellen: E-Mail-Adressen außerhalb der Organisation und deinen eigenen Endpunkt.

Fülle aus, was du möchtest, und klicke auf Speichern. Benachrichtigungen werden verschickt, nachdem der Deploy fertig ist, damit ein langsamer Endpunkt nie einen Deploy aufhält. Ein abgebrochener Deploy zählt als fehlgeschlagen.

E-Mails bei fehlgeschlagenen Deploys#

Trage unter E-Mails bei fehlgeschlagenen Deploys die Adressen ein, die eine E-Mail bekommen sollen, wenn ein Deploy dieser Site fehlschlägt, durch Kommas getrennt, höchstens 10. Sie müssen keine Mitglieder der Organisation sein. Die E-Mail nennt die Site, zeigt den Fehler und verlinkt den Deploy. Sie ist in der Sprache der Person geschrieben, die den Deploy gestartet hat.

Deploy-Hook#

Schalte Deploy-Hook ein und trage eine URL ein. Nach jedem Deploy, erfolgreich oder fehlgeschlagen, sendet Vimonto Deploy einen POST-Request mit JSON dorthin. So informierst du deine eigenen Systeme, einen Chatbot oder ein Automatisierungstool über Deploys. Die URL muss HTTPS sein und im öffentlichen Internet liegen; Weiterleitungen werden nicht verfolgt, und nach 10 Sekunden gibt der Request auf.

{
    "event": "deployment.succeeded",
    "site": { "id": 12, "domain": "shop.example.com" },
    "server": { "id": 3, "name": "web-1", "ip_address": "203.0.113.10" },
    "deployment": {
        "id": 481,
        "status": "succeeded",
        "branch": "main",
        "commit_hash": "9f2c1e7a4b...",
        "commit_message": "Fix the checkout total",
        "commit_author": "Sanne de Vries",
        "started_at": "2026-10-07T14:30:00+00:00",
        "finished_at": "2026-10-07T14:31:12+00:00",
        "url": "https://deploy.example.com/acme/servers/3/sites/12/deployments/481"
    }
}

event ist deployment.succeeded oder deployment.failed (mit status failed), oder test für einen Test-Request. Commit-Felder können null sein, wenn sie nicht bekannt sind.

Die URL ist ein Geheimnis: Sie wird verschlüsselt gespeichert und nie wieder angezeigt. Ist sie gespeichert, ist das Feld leer mit dem Hinweis „Gespeichert. Leer lassen, um es beizubehalten.“ Lass es leer, um sie zu behalten, oder gib eine neue URL ein, um sie zu ersetzen. Schalte Deploy-Hook aus und speichere, um ihn zu entfernen.

Den Deploy-Hook testen#

Ist ein Deploy-Hook gespeichert, klicke neben Speichern auf Deploy-Hook testen. Vimonto Deploy sendet die Daten des letzten Deploys der Site, mit event auf test. Du siehst Test gesendet, wenn dein Endpunkt mit einem Erfolgsstatus geantwortet hat, oder Der Test wurde nicht angenommen, wenn nicht; prüfe dann die URL. Du kannst sechs Tests pro Minute und Site senden.

Eine Site klonen#

Site klonen legt eine neue Site an, die genau wie diese ist, auf demselben oder einem anderen Server: dasselbe Repository, derselbe Branch, dieselben Build-Einstellungen, dasselbe Deploy-Skript, dieselben Benachrichtigungen und Regeln. Nutze es für eine Staging-Kopie, eine zweite Umgebung für einen Kunden oder um eine Site auf einen neuen Server umzuziehen. Der Klon wird sofort eingerichtet und deployt.

1. Klicke im Tab Allgemein unter Site klonen auf Site klonen.
2. Wähle den Server. Du kannst jeden aktiven Server wählen, auf den du Zugriff hast, außer Load Balancern.
3. Wähle die Adresse des Klons:
   • eine Adresse auf on-deploy.link, vorausgefüllt mit einem generierten Namen, den du ändern kannst (wenn generierte Adressen verfügbar sind); oder
   • klicke auf Eigene Domain verwenden und trage eine Domain ein, etwa staging.example.com. Lass sie danach auf den Server zeigen und schalte HTTPS auf der Seite Domains und SSL des Klons ein.
4. Lass Die .env kopieren eingeschaltet, damit der Klon eine Kopie der .env dieser Site bekommt (sichtbar, wenn die Site eine hat).
5. Klicke auf Site klonen.

Du landest auf der neuen Site, während sie eingerichtet wird, genau wie bei einer neuen Site. Ihr erster Deploy startet, sobald die Einrichtung fertig ist.

Was wird kopiert?#

Die kopierte .env#

Mit Die .env kopieren bekommt der Klon die .env dieser Site mit eigener APP_URL, gesetzt auf die Adresse des Klons. Alles andere bleibt gleich, der Klon nutzt also weiterhin dieselbe Datenbank, dieselben Mail-, Cache- und anderen Dienste wie das Original. Ändere diese auf der Seite Umgebung des Klons, wenn er eigene braucht, etwa eine neue Datenbank für eine Staging-Site. Im .env-Verlauf des Klons heißt diese Version Von einer anderen Site kopiert.

Mit Die .env kopieren ausgeschaltet bekommt der Klon eine neue .env, wie eine neue Site.

Site klonen gibt es für Sites mit Repository; WordPress, phpMyAdmin und Sites auf einem Load Balancer lassen sich nicht klonen.

Eine Site löschen#

1. Klicke ganz unten auf der Seite Einstellungen unter Site löschen auf Site löschen.
2. Gib zur Bestätigung die Domain der Site ein und klicke auf Site löschen.

Das Löschen läuft als Hintergrundaufgabe und entfernt vom Server:

• die Nginx-Konfiguration, ihren Include-Ordner und die Zertifikate der Site;
• die Worker und geplanten Jobs der Site;
• das Site-Verzeichnis mit allen Releases, der .env und shared/storage;
• bei einer isolierten Site ihren PHP-FPM-Pool sowie ihren Linux-Benutzer und dessen Home-Verzeichnis.

Vimonto Deploy löscht außerdem den DNS-Eintrag der generierten Adresse der Site und die DNS-Einträge, die es bei deinen DNS-Integrationen angelegt hat (der Schritt DNS-Einträge entfernen), und entfernt Deploy Key und Webhook bei deinem Git-Host. Schlägt dieses Aufräumen fehl, steht in der Ausgabe der Aufgabe, was du selbst entfernen musst.

Datenbanken und Datenbankbenutzer bleiben erhalten. Lösche sie auf der Seite Datenbanken des Servers, wenn du sie nicht mehr brauchst.

Solange eine Aufgabe auf der Site läuft, etwa ein Deployment, kannst du sie nicht löschen: Du siehst dann, dass die Site noch beschäftigt ist. Nachdem du bestätigt hast, kehrst du zur Seite Sites des Servers zurück, während die Site entfernt wird.

Wer darf Site-Einstellungen ändern?#

Jedes Mitglied kann die Einstellungen sehen, auch die Tabs für Zugangsdaten und Benachrichtigungen (ohne die gespeicherten Passwörter, Tokens und die URL des Deploy-Hooks). Zum Speichern von Änderungen, zum Hinzufügen oder Entfernen von Zugangsdaten, für Testnachrichten und zum Löschen einer Site brauchst du die Berechtigung, Sites zu verwalten (Owner, Administrator, Manager und Developer). Für Änderungen im Tab Allgemein müssen außerdem Site und Server aktiv sein. Siehe Mitglieder und Rollen.

Häufig gestellte Fragen#

Wie ändere ich die Domain einer Site?#

Auf der Seite Domains und SSL der Site. Das Verzeichnis der Site auf dem Server ändert sich dabei nicht.

Wie verbinde ich ein anderes Repository oder einen anderen Branch?#

Auf der Seite Deployments der Site.

Meine Site hat eine eigene Nginx-Konfiguration. Gelten diese Einstellungen trotzdem?#

Sie werden gespeichert, aber die Nginx-Konfiguration der Site wird nicht neu geschrieben: Mit einer eigenen Konfiguration passt du root, den PHP-FPM-Socket oder den Proxy-Port selbst darin an.

Werden meine Composer- und npm-Zugangsdaten auf dem Server gespeichert?#

Nein. Sie werden verschlüsselt in Vimonto Deploy gespeichert und nur während eines Deploys an den Build übergeben, über COMPOSER_AUTH und eine temporäre npm-Konfiguration, die danach gelöscht wird. Auf dem Server liegt keine auth.json oder .npmrc.

Warum hat mein Deploy-Hook keinen Request bekommen?#

Klicke auf Deploy-Hook testen, um zu sehen, ob dein Endpunkt mit einem Erfolgsstatus antwortet. Prüfe, ob die URL HTTPS ist, aus dem Internet erreichbar ist und nicht weiterleitet: Weiterleitungen werden nicht verfolgt.

Kann ich die Isolation für eine bestehende Site einschalten?#

Nein. Die Isolation wird beim Anlegen der Site gewählt. Lege eine neue, isolierte Site auf demselben Server an und deploye dorthin. Site klonen übernimmt die Isolation, wie sie ist: Der Klon einer Site ohne Isolation ist ebenfalls nicht isoliert.