add readme, start direct in production, less process count, more stable production

deployment/bare_metal/Readme.md

@@ -0,0 +1,46 @@
+# Deployment for bare metal servers
+This setup is designed for **bare metal servers**, offering maximum performance and reliability for Gradido deployments. However, it can also work on **virtual servers (VPS)** – if properly configured.
+
+## 🧠 Memory Considerations on VServers
+
+We have observed that some VServer providers apply **aggressive virtual memory constraints** or overcommit strategies that may cause **random crashes** of Node.js processes – even when total RAM appears sufficient.
+
+### Important Notes:
+
+- A single Node.js process may **allocate 10–12 GB of virtual memory** (VIRT), even if **real memory usage (RES)** stays below 200 MB.
+- Some VPS environments **panic or kill processes** when virtual memory allocation exceeds certain invisible thresholds.
+
+## 🛡️ Rate Limiting (API Protection)
+
+This deployment includes built-in **rate limiting** for public-facing endpoints to prevent abuse and denial-of-service attacks.
+
+### 🔒 NGINX Rate & Connection Limits Overview
+
+| Path                        | Zone     | Rate Limit     | Burst | Max Connections | Notes                          |
+|----------------------------|----------|----------------|-------|------------------|--------------------------------|
+| `/`                        | frontend | 15 requests/s  | 150   | 60               | Public frontend                |
+| `/admin`                   | frontend | 15 requests/s  | 30    | 20               | Admin frontend                 |
+| `/graphql`                 | backend  | 20 requests/s  | 40    | 20               | Main backend GraphQL API       |
+| `/hook`                    | backend  | 20 requests/s  | 20    | 20               | Internal backend webhooks      |
+| `/hooks/`                  | backend  | 20 requests/s  | 20    | 20               | Reverse proxy for webhooks     |
+| `/api/<version>` | api   | 30 requests/s  | 60    | 30               | Federation GraphQL API            |
+
+- `<version>`: placeholder for federation api version
+- All zones use `$binary_remote_addr` for client identification.
+- `nodelay` ensures burst requests are not delayed (they are either accepted or rejected).
+- Global connection zone: `limit_conn_zone $binary_remote_addr zone=addr:10m;`
+
+This setup helps protect public and internal interfaces from abuse, while ensuring smooth parallel access during high load periods (e.g., UI builds or cluster sync).
+
+These limits work like a traffic cop at each route:
+- **Rate limits** (`limit_req`) define how many requests per second a single client can send.
+- **Burst values** allow short spikes without blocking – like a temporary buffer.
+- **Connection limits** (`limit_conn`) cap how many concurrent connections a single IP can keep open.
+
+Each route (frontend, backend, API, etc.) has its own configuration depending on its expected traffic pattern and sensitivity. For example:
+- The public frontend allows higher bursts (many assets load at once).
+- The GraphQL backend and admin interfaces are more tightly controlled.
+
+This ensures fairness, avoids accidental DoS scenarios, and keeps overall latency low, even under high usage.
+
+

deployment/bare_metal/start.sh

@@ -287,7 +287,7 @@ else
 fi
 
 # start after building all to use up less ressources
-pm2 start --name gradido-backend "turbo backend#start --env-mode=loose" -l $GRADIDO_LOG_PATH/pm2.backend.$TODAY.log --log-date-format 'YYYY-MM-DD HH:mm:ss.SSS'
+pm2 start --name gradido-backend "env TZ=UTC NODE_ENV=production node ./backend/build/index.js" -l $GRADIDO_LOG_PATH/pm2.backend.$TODAY.log --log-date-format 'YYYY-MM-DD HH:mm:ss.SSS'
 #pm2 start --name gradido-frontend "yarn --cwd $PROJECT_ROOT/frontend start" -l $GRADIDO_LOG_PATH/pm2.frontend.$TODAY.log --log-date-format 'YYYY-MM-DD HH:mm:ss.SSS'
 #pm2 start --name gradido-admin "yarn --cwd $PROJECT_ROOT/admin start" -l $GRADIDO_LOG_PATH/pm2.admin.$TODAY.log --log-date-format 'YYYY-MM-DD HH:mm:ss.SSS'
 pm2 save