# Site-Einstellungen: PHP-Version, Web-Verzeichnis, Isolation > PHP-Version, Web-Verzeichnis oder Zero-Downtime-Deploys einer Site ändern, Composer- und npm-Zugangsdaten hinterlegen, Fehler-E-Mails und Deploy-Hook setzen. 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: | Tab | Was er enthält | Zu sehen bei | | --- | --- | --- | | **Allgemein** | PHP-Version, Web-Verzeichnis oder Port, Zero-Downtime-Deploys, Isolation, [**Site klonen**](#eine-site-klonen) und **Site löschen** | Jeder Site | | **Composer** | [Zugangsdaten für private Composer-Pakete](#zugangsdaten-für-composer-und-npm) | Laravel-, Symfony-, Statamic- und PHP-Sites | | **npm** | [Tokens für private npm-Registrys](#zugangsdaten-für-composer-und-npm) | Sites mit Repository | | **Benachrichtigungen** | [E-Mails bei fehlgeschlagenen Deploys und ein Deploy-Hook](#deploy-benachrichtigungen) | Sites mit Repository | WordPress, phpMyAdmin und Sites auf einem Load Balancer haben kein Repository und keinen Build. Sie haben deshalb nur die allgemeinen Einstellungen und keine Tabs. ![Die Seite Einstellungen einer Laravel-Site mit PHP-Version, Web-Verzeichnis, Schalter für Zero-Downtime-Deploys und Website-Isolation](https://ops.vimonto.com/docs-media/de/site-settings.webp?v=161e760d "Die Einstellungen einer Site") ## 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: ```text /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 ``` | Einstellung | Wo du sie festlegst | Später änderbar? | | --- | --- | --- | | Verzeichnis (oben `example.com`) | Beim [Anlegen der Site](https://ops.vimonto.com/docs/de/sites/create-a-site) | Nein. Es bleibt gleich, wenn sich die Domain ändert. | | Root-Verzeichnis, für ein Monorepo | Beim Anlegen der Site | Nein. | | Web-Verzeichnis | Einstellungen | Ja | | PHP-Version | Einstellungen | Ja | | Port einer Node.js-App | Einstellungen | Ja | | Zero-Downtime-Deploys | Einstellungen | Ja | | Website-Isolation | Beim Anlegen der Site | Nein | | Domain und Aliase | [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-ssl) | Ja | | Repository und Branch | [Deployments](https://ops.vimonto.com/docs/de/sites/deployments) | Ja | 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](https://ops.vimonto.com/docs/de/sites/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](https://ops.vimonto.com/docs/de/sites/load-balancing), wo du sie verwaltest. **Site löschen** gibt es dort wie bei jeder Site. ![Die Übersicht einer Site mit Adresse, Verzeichnis, Web-Root, Repository, Branch und den letzten Deployments](https://ops.vimonto.com/docs-media/de/site-overview.webp?v=161e760d "Die Übersicht einer 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](https://ops.vimonto.com/docs/de/servers/php) des Servers. > [!WARNING] > Queue Worker und geplante Jobs der Site nutzen weiterhin die vorherige PHP-Version. Lege sie nach dem Wechsel auf der Seite [Queues und Scheduler](https://ops.vimonto.com/docs/de/sites/queues-and-scheduler) neu an. Eine Benachrichtigung erinnert dich daran, wenn die Site welche hat. 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](https://ops.vimonto.com/docs/de/sites/queues-and-scheduler#eine-nodejs-app-betreiben)), 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. | | An | Aus | | --- | --- | --- | | Wo ein Deployment baut | In einem neuen Release-Verzeichnis | In `releases/live`, direkt vor Ort | | Ein fehlgeschlagener Build | Wird verworfen; die Live-Site bleibt unverändert | Bleibt in der Live-Site | | Rollback | Ja | Nein | | Alte Releases | Werden nach jedem Deployment aufgeräumt | Entfällt | Die Änderung gilt ab dem nächsten Deployment. Siehe [Deployments](https://ops.vimonto.com/docs/de/sites/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](https://ops.vimonto.com/docs/de/sites/create-a-site); danach lässt sie sich nicht mehr ändern. | | Isolation an | Isolation aus | | --- | --- | --- | | Linux-Benutzer | Ein eigener Benutzer, zum Beispiel `shop` | Der Systembenutzer des Servers (`vimonto`), geteilt mit anderen Sites | | Home-Verzeichnis | `/home/shop`, nur für diesen Benutzer und seine Gruppe lesbar | `/home/vimonto` | | PHP-FPM | Ein eigener Pool, der als Benutzer der Site auf `/run/php/site-{id}.sock` läuft | Der gemeinsame Pool der PHP-Version | | Deployments, Worker, geplante Jobs | Laufen als Benutzer der Site | Laufen als Systembenutzer | 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](https://ops.vimonto.com/docs/de/sites/create-a-site#private-composer--und-npm-pakete) unter **Composer-Authentifizierung** und **npm-Authentifizierung** eintragen kannst. ![Der Tab Composer in den Einstellungen einer Site mit gespeicherten Zugangsdaten für repo.packagist.com](https://ops.vimonto.com/docs-media/de/site-composer.webp?v=161e760d "Authentifizierung für Composer-Pakete") ### 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](https://ops.vimonto.com/docs/de/more/notifications) 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. ![Der Tab Benachrichtigungen in den Einstellungen einer Site mit den E-Mails bei fehlgeschlagenen Deploys und dem Deploy-Hook](https://ops.vimonto.com/docs-media/de/site-notifications.webp?v=161e760d "Deploy-Benachrichtigungen einer Site") 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. ```json { "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](https://ops.vimonto.com/docs/de/sites/create-a-site#was-passiert-nachdem-du-auf-site-anlegen-geklickt-hast). Ihr erster Deploy startet, sobald die Einrichtung fertig ist. ### Was wird kopiert? | Kopiert | Nicht kopiert | | --- | --- | | Framework, Repository, Branch und Git-Verbindung | Datenbanken und Datenbankbenutzer | | Build-Einstellungen (Composer, Paketmanager, Build-Befehl) | Zertifikate | | PHP-Version, wenn sie auf dem Zielserver installiert ist (sonst die Standardversion des Servers) | Queue Worker und Prozesse | | Web-Verzeichnis und Monorepo-Root | [Site-Features](https://ops.vimonto.com/docs/de/sites/site-features) | | Zero-Downtime-Deploys | Dateien, die die App gespeichert hat, etwa `shared/storage` | | Website-Isolation, mit demselben Benutzernamen (mit angehängter Zahl, wenn der Server ihn schon hat) | | | Composer- und npm-Zugangsdaten | | | Deploy-Skript und Quick Deploy | | | Deploy-Benachrichtigungen | | | [Weiterleitungen](https://ops.vimonto.com/docs/de/sites/redirects) und [Sicherheitsregeln](https://ops.vimonto.com/docs/de/sites/security-rules) | | | Der Deploy-Key, bei einem Repository ohne Git-Verbindung | | ### 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](https://ops.vimonto.com/docs/de/sites/environment) 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](https://ops.vimonto.com/docs/de/connections/integrations) 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](https://ops.vimonto.com/docs/de/servers/databases) 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. > [!WARNING] > Das Löschen einer Site lässt sich nicht rückgängig machen. Lade vorher alles herunter, was du aus `shared/storage` brauchst, und bewahre eine Kopie der `.env` auf. ## 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](https://ops.vimonto.com/docs/de/organization/members-and-roles). ## Häufig gestellte Fragen ### Wie ändere ich die Domain einer Site? Auf der Seite [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-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](https://ops.vimonto.com/docs/de/sites/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](https://ops.vimonto.com/docs/de/sites/nginx#was-ändert-sich-wenn-du-deine-eigene-konfiguration-verwendest) 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.