Create modules and deploy for the first time

A module is a deployable piece of your project: the frontend, the backend, a Node service. Per module FlawDesk knows where in the repository the code lives, how it is built and where the result goes on the server. A small project has one module, a typical web app two (frontend + backend).

Prerequisites

• Server connected, server status green
• GitHub connected and repository cloned on the server

1. Create a module

Project settings → FlawDesk Code → Modules → Add module. The form:

The most important stacks:

• Static site (React / Vue / Vite) — npm run build → dist/ is copied to the server as static files. For everything a web server serves directly.
• Node server (Express / Fastify / NestJS) — code is copied, npm ci runs on the server, pm2 restarts the service. Hence the pm2 app name.
• PHP backend — code is copied via rsync, no build step. .env and similar files stay untouched (see sticky files).
• .NET (C#), Python, Android app, Custom — for the respective special cases; Android and .NET have their own guides.

The stack is only a preset — every field can be adjusted afterwards.

2. Define sticky files

A deploy brings the target folder to the state of the build — files that do not exist in the build are removed there. Configuration files that exist only on the server (.env, config.local.php, uploaded files) must therefore be protected:

FlawDesk Code → Sticky files → enter the path relative to the deploy path, e.g. .env or config/app.local.php. Sticky files are backed up before every deploy and restored afterwards; they also cannot be overwritten or deleted through the connector.

3. Start the first deploy

1. Open Deployment in the left rail and pick the project. Every module has a card with type, deploy path and last state. 2. Click Deploy … on the card. A dialog opens: "Build and deploy module Frontend now." 3. Start build & deploy.

What happens then, in this order:

1. Check — Is the workspace on the server pushed? Unpushed changes are shown as a hint so that an old state does not go live by accident. 2. Build — the build command runs in the workspace on the server. The result is stored as a separate build (with timestamp and commit). 3. Deploy — the build is transferred to the deploy path via rsync; for Node modules npm ci and the pm2 restart follow.

The window shows every step with its log. You can minimise it with the X — it becomes a small card at the bottom right, the process keeps running, and you can continue working in FlawDesk normally. Clicking the card brings the window back; after reloading the page the card is still there.

4. After the deploy

• Build history — Builds on the module card shows all previous builds with status, commit and logs.
• Rollback — in the deploy dialog choose Deploy from existing build and pick an earlier build. Nothing is rebuilt, only the old state is transferred again.
• Skip build — deploys the latest existing build again, e.g. after a sticky file rule was added.

Common problems

Build fails with "command not found" — The tool (npm, php, dotnet) is not installed on the server. Server status → Check now shows what is missing.

Deploy path not writable — The SSH user has no write access in the target directory. On the server: chown -R /var/www/my-app.

.env missing after the deploy — It was not registered as a sticky file. Register it, recreate the file, from then on it is kept.

Node service not running after the deploy — Check the pm2 app name in the module; it must match the name in pm2 (pm2 list on the server).

Next

From here you work normally: create a ticket, change code, push, deploy. If an AI client should do that for you:

• Set up the AI connector
• Securing SSH — before the connector gets access