Site-Features: Horizon, Reverb, Pulse, WordPress und mehr

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 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; ö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, die die Include-Zeile für zusätzliche Direktiven behält.

Welche Features gibt es?#

Prozesse laufen unter Supervisor als Benutzer der Site und erscheinen auf der Seite Queues und 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.

Horizon#

Arbeitet deine Redis-Queues mit Laravel 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 zeigen).

Reverb#

Betreibt Laravel 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 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 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:

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 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, 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 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 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. 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 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 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. 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, 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 oder Serverprozesse an.