Module anlegen und zum ersten Mal deployen

Ein Modul ist ein deploybares Stück deines Projekts: das Frontend, das Backend, ein Node-Dienst. Pro Modul weiß FlawDesk, wo im Repository der Code liegt, wie er gebaut wird und wohin das Ergebnis auf dem Server kommt. Ein kleines Projekt hat ein Modul, eine typische Web-App zwei (frontend + backend).

Voraussetzungen

Server verbunden, Server-Status grün
GitHub verbunden und Repository auf dem Server geklont

1. Modul anlegen

Projekteinstellungen → FlawDesk Code → Module → Modul hinzufügen. Das Formular:

Feld	Bedeutung
Name	Anzeigename, z. B. `Frontend`
Stack	Vorlage, die Build und Deploy vorbelegt (siehe unten)
Pfad im Repo	Unterordner, in dem der Modul-Code liegt. `.` = Repository-Wurzel, `backend` = Ordner `backend/`
Build-Command	Befehl, der den Build erzeugt, z. B. `npm run build`. Leer = kein Build, der Quellordner wird direkt deployt
Build-Output	Ordner mit dem Build-Ergebnis, z. B. `dist`. Leer = der Quellordner selbst
Deploy-Pfad	Zielverzeichnis auf dem Server, z. B. `/var/www/meine-app/frontend`. FlawDesk schlägt einen Pfad vor
pm2-App-Name	Nur Node Server: Name des Prozesses, den pm2 nach dem Deploy neu startet

Die wichtigsten Stacks:

Static Site (React / Vue / Vite) — npm run build → dist/ wird als statische Dateien auf den Server kopiert. Für alles, was ein Webserver direkt ausliefert.
Node Server (Express / Fastify / NestJS) — Code wird kopiert, npm ci läuft auf dem Server, pm2 startet den Dienst neu. Deshalb der pm2-App-Name.
PHP Backend — Code wird per rsync kopiert, kein Build-Schritt. .env und ähnliche Dateien bleiben unangetastet (siehe Sticky-Files).
.NET (C#), Python, Android App, Custom — für die jeweiligen Sonderfälle; Android und .NET haben eigene Anleitungen.

Der Stack ist nur eine Vorbelegung — jedes Feld kannst du danach anpassen.

2. Sticky-Files festlegen

Ein Deploy bringt den Zielordner auf den Stand des Builds — Dateien, die es im Build nicht gibt, werden dort entfernt. Konfigurationsdateien, die nur auf dem Server existieren (.env, config.local.php, hochgeladene Dateien), musst du deshalb schützen:

FlawDesk Code → Sticky-Files → Pfad relativ zum Deploy-Pfad eintragen, z. B. .env oder config/app.local.php. Sticky-Files werden vor jedem Deploy gesichert und danach wiederhergestellt; auch über den Connector lassen sie sich nicht überschreiben oder löschen.

⚠️ Lege Sticky-Files vor dem ersten Deploy an, wenn im Zielordner schon eine .env liegt. Sonst ist sie nach dem Deploy weg.

3. Ersten Deploy starten

1. In der linken Leiste Deployment öffnen und das Projekt wählen. Jedes Modul hat eine Karte mit Typ, Deploy-Pfad und letztem Stand. 2. Auf der Karte auf Deploy … klicken. Es öffnet sich ein Dialog: „Modul Frontend jetzt bauen und deployen." 3. Build & Deploy starten.

Was dann passiert, in dieser Reihenfolge:

1. Prüfung — Ist der Workspace auf dem Server gepusht? Nicht gepushte Änderungen bekommst du als Hinweis angezeigt, damit nicht versehentlich ein alter Stand live geht. 2. Build — der Build-Command läuft im Workspace auf dem Server. Das Ergebnis wird als eigenständiger Build abgelegt (mit Zeitstempel und Commit). 3. Deploy — der Build wird per rsync in den Deploy-Pfad übertragen; bei Node-Modulen folgen npm ci und der pm2-Neustart.

Das Fenster zeigt jeden Schritt mit Log. Du kannst es mit dem X minimieren — es wird zu einer kleinen Karte unten rechts, der Vorgang läuft weiter, und du kannst in FlawDesk normal weiterarbeiten. Klick auf die Karte holt das Fenster zurück; nach einem Neuladen der Seite ist die Karte ebenfalls noch da.

ℹ️ Voraussetzung ist die Berechtigung Deploy auslösen (bzw. Builds auslösen) in der Berechtigungsgruppe des Nutzers. Fehlt sie, ist der Knopf ausgegraut.

4. Nach dem Deploy

Build-Historie — Builds auf der Modulkarte zeigt alle bisherigen Builds mit Status, Commit und Logs.
Rollback — im Deploy-Dialog Aus bestehendem Build deployen wählen und einen früheren Build auswählen. Es wird nichts neu gebaut, nur der alte Stand wieder übertragen.
Build überspringen — deployt den letzten vorhandenen Build erneut, z. B. nachdem eine Sticky-File-Regel ergänzt wurde.

Häufige Probleme

Build schlägt fehl mit „command not found" — Das Werkzeug (npm, php, dotnet) ist auf dem Server nicht installiert. Server-Status → Jetzt prüfen zeigt, was fehlt.

Deploy-Pfad nicht beschreibbar — Der SSH-User hat im Zielverzeichnis keine Schreibrechte. Auf dem Server: chown -R /var/www/meine-app.

Nach dem Deploy fehlt die .env — Sie war nicht als Sticky-File eingetragen. Eintragen, Datei neu anlegen, ab dann bleibt sie erhalten.

Node-Dienst läuft nach dem Deploy nicht — pm2-App-Name im Modul prüfen; er muss dem Namen in pm2 entsprechen (pm2 list auf dem Server).

Weiter geht's

Ab hier arbeitest du normal: Ticket anlegen, Code ändern, pushen, deployen. Wenn ein KI-Client das für dich übernehmen soll:

KI-Connector einrichten
SSH absichern — bevor der Connector Zugriff bekommt