# Site-Features: Horizon, Reverb, Pulse, WordPress und mehr > Laravel Horizon, Reverb, Pulse, Inertia SSR, Nightwatch, Symfony Messenger, WordPress-Cron und Redis, Wartungsmodus oder Passwortschutz per Klick aktivieren. **Site-Features** sind fertige Setups für die Tools, die dein Framework nutzt, etwa Laravel Horizon, Reverb oder den Cron von WordPress. Du schaltest sie im Framework-Menü im Site-Header ein, und Vimonto Deploy richtet alles, was das Tool braucht, auf dem Server ein: Supervisor-Prozesse, Cronjobs, Nginx-Direktiven und `.env`-Werte. Der Dialog jedes Features zeigt dir genau, was er einrichtet, bevor du ihn einschaltest. Wo nötig, werden Features nach jedem Deployment neu gestartet. Das Menü und der Button **Öffnen** daneben erscheinen, sobald die erste Einrichtung der Site fertig und ihre erste Version live ist. ![Das Laravel-Feature-Menü im Site-Header mit eingeschaltetem Horizon und Scheduler](https://ops.vimonto.com/docs-media/de/site-features-menu.webp?v=161e760d "Das Framework-Menü einer Laravel-Site") ![Das Feature-Menü öffnen und den Dialog eines Features anzeigen](https://ops.vimonto.com/docs-media/de/site-features.mp4?v=161e760d) ## Das Feature-Menü öffnen Das Menü sitzt im Site-Header und trägt den Namen des Frameworks der Site, zum Beispiel **Laravel** oder **WordPress**. Es öffnet sich mit den Features des Frameworks, etwa **Laravel-Funktionen**, mit einem grünen Punkt für die eingeschalteten und einem Zähler wie **2 von 7 aktiv**. Vimonto Deploy liest bei jedem Deployment die Pakete in deiner `composer.json` und `package.json`. Features, deren Paket deine App nutzt, sind mit **In deinem Code** markiert und stehen zusammen mit den bereits eingeschalteten Features oben; die anderen findest du unter **Alle anzeigen (… weitere, nicht in deinem Code gefunden)**. Bis zum ersten Deployment werden alle Features aufgelistet. ## Ein Feature ein- oder ausschalten 1. Klicke im Menü auf das Feature, um seinen Dialog zu öffnen. 2. Fülle seine Einstellungen aus, falls es welche hat. 3. Prüfe **Was wir einrichten** und **Wir setzen in deiner .env**. Schlüssel, deren Wert sich ändert, sind mit **ändert sich** markiert. 4. Klicke auf **Einschalten**. Das Einschalten läuft als Hintergrundaufgabe, die du im Site-Header verfolgen kannst. Schlägt es fehl, zeigt das Feature im Menü **Fehlgeschlagen**, und du bekommst eine [Benachrichtigung](https://ops.vimonto.com/docs/de/more/notifications); öffne es und klicke auf **Speichern**, um es erneut zu versuchen, oder auf **Erneut versuchen** bei einem Feature ohne Einstellungen, etwa dem Scheduler oder Pulse. Beides wendet dieselben Einstellungen erneut an. Um die Einstellungen eines eingeschalteten Features zu ändern, öffnest du es, änderst sie und klickst auf **Speichern**. Zum Ausschalten öffnest du es und klickst auf **Ausschalten**: Seine Prozesse, Cronjobs und Nginx-Direktiven werden entfernt. Werte, die es in der `.env` gesetzt hat, bleiben erhalten. Features brauchen eine eingerichtete und meist auch deployte Site, denn ihre Befehle laufen im Live-Release. Features mit Nginx-Direktiven brauchen die generierte Nginx-Konfiguration der Site oder eine [eigene Konfiguration](https://ops.vimonto.com/docs/de/sites/nginx), die die Include-Zeile für zusätzliche Direktiven behält. ## Welche Features gibt es? | Feature | Frameworks | Was es einrichtet | |---|---|---| | [Scheduler](#scheduler) | Laravel, Statamic | Cron: `schedule:run` jede Minute | | [Horizon](#horizon) | Laravel, Statamic | Prozess: `artisan horizon` | | [Reverb](#reverb) | Laravel, Statamic | Prozess, Nginx, DNS, `.env` | | [Pulse](#pulse) | Laravel, Statamic | Prozess: `artisan pulse:check` | | [Inertia SSR](#inertia-ssr) | Laravel, Statamic | Prozess: `artisan inertia:start-ssr` | | [Nightwatch](#nightwatch) | Laravel, Statamic | Prozess: `artisan nightwatch:agent`, `.env` | | [Messenger-Worker](#messenger-worker) | Symfony | Prozesse: `messenger:consume` | | [Echter Cron](#echter-cron-für-wordpress) | WordPress | Cron: WP-CLI jede Minute | | [Redis-Objekt-Cache](#redis-objekt-cache-für-wordpress) | WordPress | WordPress-Plugin | | [Härtung](#härtung-für-wordpress) | WordPress | Nginx-Regeln, Konstante in `wp-config.php` | | [Wartungsmodus](#wartungsmodus) | Laravel, Statamic, WordPress | `artisan down` oder WP-CLI | | [Passwortschutz](#passwortschutz) | Alle, auch lastverteilte Sites | Nginx Basic Authentication | Prozesse laufen unter Supervisor als Benutzer der Site und erscheinen auf der Seite [Queues und Scheduler](https://ops.vimonto.com/docs/de/sites/queues-and-scheduler) mit einem Badge **Über …**. Cronjobs laufen als Benutzer der Site. ## Laravel-Features ### Scheduler Führt deine geplanten Befehle aus: Ein Cron-Eintrag startet jede Minute `php artisan schedule:run` im Live-Release. Das ist derselbe Schalter wie **Aktivieren** auf der Seite [Queues und Scheduler](https://ops.vimonto.com/docs/de/sites/queues-and-scheduler#den-laravel-scheduler-aktivieren). ### Horizon Arbeitet deine Redis-Queues mit [Laravel Horizon](https://laravel.com/docs/horizon) ab: Ein Supervisor-Programm führt `php artisan horizon` aus und startet damit jeden Worker, den deine `config/horizon.php` beschreibt. - **Einstellung**: **Längster Job (Sekunden)**, standardmäßig 3600. Bei einem Deployment haben laufende Jobs so lange Zeit, fertig zu werden, bevor der Prozess gestoppt wird. - **Nach jedem Deployment**: `php artisan horizon:terminate`, damit Horizon seine Jobs abschließt und Supervisor es mit dem neuen Code startet. - **.env**: `QUEUE_CONNECTION=redis`. - **Link**: das **Horizon-Dashboard** unter `/horizon`. Der Dialog warnt dich, wenn die Site zusätzlich eigene Queue Worker hat (entferne sie, damit Jobs nicht doppelt abgearbeitet werden) und wenn auf dem Server kein Redis läuft (lass `REDIS_HOST` dann auf einen [Cache-Server](https://ops.vimonto.com/docs/de/servers/server-types) zeigen). ### Reverb Betreibt [Laravel Reverb](https://laravel.com/docs/reverb), den WebSocket-Server für Broadcasting, unter einer eigenen WebSocket-Adresse. - **WebSocket-Adresse**: standardmäßig `ws.` plus die Domain der Site, etwa `ws.shop.example.com`. - **Lokaler Port**: der Port, auf dem Reverb lauscht, nur auf dem Server selbst, ab 8080 aufwärts. Jede App auf dem Server braucht einen eigenen. Wenn du es einschaltest, macht Vimonto Deploy Folgendes: - Es führt `php artisan reverb:start --host=127.0.0.1 --port=…` unter Supervisor aus. - Es fügt die WebSocket-Adresse zu den Namen der Site hinzu und legt Nginx-Regeln an, die `/app/` (WebSocket-Verbindungen) und `/apps/` (die HTTP-API von Reverb) an Reverb weiterleiten. - Es legt den DNS-Eintrag an, wenn die Adresse auf `on-deploy.link` liegt oder die Domain der Site von einer verbundenen [DNS-Integration](https://ops.vimonto.com/docs/de/connections/integrations) verwaltet wird; ein Eintrag dort, der woandershin zeigt und nicht von Vimonto Deploy angelegt wurde, bleibt unverändert, und der Task sagt das. Sonst listet der Dialog den A-Record auf, den du anlegen musst, mit der IP-Adresse des Servers als Ziel. - Es beantragt ein neues Let's-Encrypt-Zertifikat inklusive der WebSocket-Adresse, wenn die Site bereits eines hat und der Name auf den Server zeigt. Andernfalls beantragst du unter [Domains und SSL](https://ops.vimonto.com/docs/de/sites/domains-and-ssl) ein neues Zertifikat, sobald der DNS-Eintrag steht. - Es führt nach jedem Deployment `php artisan reverb:restart` aus. Es setzt diese Schlüssel in der `.env`. App-ID, Key und Secret von Reverb werden übernommen, wenn deine `.env` sie schon enthält, und sonst generiert: ```ini BROADCAST_CONNECTION=reverb REVERB_APP_ID=… REVERB_APP_KEY=… REVERB_APP_SECRET=… REVERB_HOST=ws.shop.example.com REVERB_PORT=443 REVERB_SCHEME=https REVERB_SERVER_HOST=127.0.0.1 REVERB_SERVER_PORT=8080 VITE_REVERB_APP_KEY="${REVERB_APP_KEY}" VITE_REVERB_HOST="${REVERB_HOST}" VITE_REVERB_PORT="${REVERB_PORT}" VITE_REVERB_SCHEME="${REVERB_SCHEME}" ``` Ohne HTTPS auf der Site ist `REVERB_PORT` gleich `80` und `REVERB_SCHEME` gleich `http`. Deploye danach erneut, damit dein Frontend-Build die `VITE_`-Werte übernimmt. Sobald Reverb läuft, zeigt der Dialog die vollständige **WebSocket-Adresse**, mit der sich deine Clients verbinden. ### Pulse Hält `php artisan pulse:check` am Laufen, damit das Dashboard von [Laravel Pulse](https://laravel.com/docs/pulse) CPU, Arbeitsspeicher und Festplatte des Servers zeigt. Es führt nach jedem Deployment `pulse:restart` aus und verlinkt auf das **Pulse-Dashboard** unter `/pulse`. ### Inertia SSR Rendert Inertia-Seiten auf dem Server, für schnellere erste Ladezeiten und bessere Ergebnisse in Suchmaschinen. Es führt `php artisan inertia:start-ssr` unter Supervisor aus und nach jedem Deployment `inertia:stop-ssr`, damit der Server-Renderer mit dem neuen Bundle neu startet. - Baue das SSR-Bundle auch in deinem [Deploy-Skript](https://ops.vimonto.com/docs/de/sites/deployments#das-deploy-skript-bearbeiten), zum Beispiel `npm run build && npx vite build --ssr`. Der Dialog warnt dich, wenn er dort kein `--ssr` findet. - Der Server braucht Node.js (App- und Webserver haben es). - Der SSR-Server lauscht auf dem Port von Inertia, 13714. Deshalb kann es pro Server nur eine Site nutzen. ### Nightwatch Hält den Agent von [Laravel Nightwatch](https://nightwatch.laravel.com) am Laufen (`php artisan nightwatch:agent`), damit deine App an Nightwatch berichtet. - **Einstellung**: **Nightwatch-Token**, aus deiner Anwendung auf nightwatch.laravel.com. Lässt du das Feld später leer, bleibt der aktuelle Token erhalten. - **.env**: `NIGHTWATCH_TOKEN`, im Dialog maskiert angezeigt. ## Symfony-Features ### Messenger-Worker Führt `bin/console messenger:consume` für deine Transports von [Symfony Messenger](https://symfony.com/doc/current/messenger.html) aus, mit `--time-limit=3600 --env=prod`. - **Transports**: durch Leerzeichen getrennt und nach Priorität geordnet, etwa `async scheduler_default`. Standard: `async`. - **Prozesse**: wie viele Worker parallel laufen (1 bis 20). - **Nach jedem Deployment**: `messenger:stop-workers`, damit Supervisor sie mit dem neuen Code startet. ## WordPress-Features Die WordPress-Features nutzen [WP-CLI](https://wp-cli.org). Vimonto Deploy installiert es auf dem Server (als `/usr/local/bin/wp`), sobald ein Feature es zum ersten Mal braucht. ### Echter Cron für WordPress WordPress führt seine geplanten Aufgaben normalerweise aus, wenn jemand eine Seite aufruft. Auf ruhigen Sites fallen sie dadurch aus, auf stark besuchten bremsen sie. **Echter Cron** setzt `DISABLE_WP_CRON` in `wp-config.php` und führt stattdessen jede Minute `wp cron event run --due-now` über einen echten Cronjob aus. Beim Ausschalten wird die Konstante wieder entfernt. ### Redis-Objekt-Cache für WordPress Installiert und aktiviert das Plugin [Redis Object Cache](https://wordpress.org/plugins/redis-cache/) und schaltet den Cache ein, damit WordPress der Datenbank nicht bei jeder Anfrage dieselben Fragen stellt. Es braucht Redis auf dem Server; auf Servern ohne Redis ist das Feature nicht verfügbar. Beim Ausschalten wird der Cache deaktiviert und das Plugin deaktiviert. ### Härtung für WordPress Schließt die Türen, durch die Angriffe auf WordPress meist kommen: - Nginx sperrt `xmlrpc.php`. - Nginx führt keine PHP-Dateien in `wp-content/uploads` aus. - `DISALLOW_FILE_EDIT` schaltet den Theme- und Plugin-Dateieditor im Dashboard ab. ## Wartung und Zugriff ### Wartungsmodus Zeigt Besuchern eine Wartungsseite, bis du ihn ausschaltest. Solange er aktiv ist, zeigt der Site-Header **Wartungsmodus**; ein Klick darauf öffnet den Dialog. - **Laravel und Statamic**: führt `php artisan down` mit einem Secret und `--retry=60` aus. Der Dialog zeigt einen **Umgehungslink (setzt ein Cookie)**, mit dem du die Site wie gewohnt siehst. Bei jedem Einschalten wird das Secret neu erzeugt, ein alter Link funktioniert dann nicht mehr. Der Zustand liegt in `storage/`, das zwischen Releases geteilt wird; er übersteht also Deployments. - **WordPress**: führt `wp maintenance-mode activate` aus. ### Passwortschutz Fragt nach Benutzername und Passwort (HTTP Basic Authentication), bevor jemand die Site sieht: praktisch für Staging-Sites und Vorschauen unter der `on-deploy.link`-Adresse. - **Benutzername**: standardmäßig `preview`; Buchstaben, Ziffern, `.`, `_` und `-`. - **Passwort**: mindestens 8 Zeichen. Gespeichert wird nur ein bcrypt-Hash. Lässt du das Feld später leer, bleibt das aktuelle Passwort erhalten. Let's Encrypt erreicht die Site auch im geschützten Zustand, um Zertifikate auszustellen und zu erneuern. Bei einer [lastverteilten Site](https://ops.vimonto.com/docs/de/sites/load-balancing) ist der Passwortschutz das einzige Feature, und er schützt alle App-Server hinter dem Balancer auf einmal. Um nur einen Pfad wie `/admin` zu schützen oder mehreren Personen eine eigene Anmeldung zu geben, nutze stattdessen [Sicherheitsregeln](https://ops.vimonto.com/docs/de/sites/security-rules). Eine Sicherheitsregel für die ganze Site und der Passwortschutz können nicht gleichzeitig aktiv sein. ## Häufig gestellte Fragen ### Was bedeutet „In deinem Code“? Das Paket des Features steht seit dem letzten Deployment in deiner `composer.json` oder `package.json`, zum Beispiel `laravel/horizon` für Horizon. Features, die nicht gefunden wurden, kannst du trotzdem einschalten; öffne **Alle anzeigen**, um sie zu sehen. ### Entfernt das Ausschalten eines Features seine .env-Werte? Nein. Prozesse, Cronjobs und Nginx-Direktiven werden entfernt, aber Werte, die das Feature in der `.env` gesetzt hat, bleiben. Bearbeite sie auf der Seite [Umgebung](https://ops.vimonto.com/docs/de/sites/environment), wenn du sie nicht mehr brauchst. ### Warum ist ein Feature nicht verfügbar? Der Dialog nennt den Grund, zum Beispiel **Auf diesem Server läuft kein Redis.**, **Dieser Server hat kein Node.js.** oder dass die Site eine eigene Nginx-Konfiguration ohne das Include für zusätzliche Direktiven hat. ### Kann ich den Prozess eines Features selbst ändern? Nicht direkt. Prozesse und Cronjobs, die ein Feature angelegt hat, werden nur über das Feature geändert und entfernt, damit sie immer zu seinen Einstellungen passen. Für alles andere legst du eigene [Queue Worker](https://ops.vimonto.com/docs/de/sites/queues-and-scheduler) oder [Serverprozesse](https://ops.vimonto.com/docs/de/servers/processes) an.