5.2 KiB
5.2 KiB
LeoCRM Deploy Guide
Version: 2.0
Date: 2026-08-20
Fast Frontend-Only Deploy (~20s)
bash /a0/usr/projects/leocrm/scripts/fast-deploy.sh frontend
- Baut Frontend lokal, kopiert dist/ direkt in den laufenden Container
- Kein Coolify-Rebuild, kein Docker-Image-Neubau
- Container wird nicht neu gestartet
- Findet Container-Namen automatisch
Full Deploy (~2min, fuer Backend-Aenderungen)
bash /a0/usr/projects/leocrm/scripts/fast-deploy.sh full
- Triggert Coolify-Rebuild ueber deploy.py
- Fuer Python-Code, Requirements, Migrations
Wann was?
- Nur Frontend (TSX, CSS, etc.):
frontend - Backend (Python, Dockerfile, requirements):
full - Beides: erst
full, dannfrontend(oder nurfull)
Git Workflow
- Aenderungen in /a0/usr/projects/leocrm
git add -A && git commit -m '...' && git push origin main- Dann deploy
Container-Info
- Coolify App UUID: xf7smknlger3hvkrsb910tui (neu erstellt 2026-08-06)
- Container-Name aendert sich bei jedem Coolify-Deploy (Suffix)
- Frontend-Pfad im Container: /app/frontend/dist
- Worker: Teil der Docker-Compose-App (crm_worker service)
- DB: Teil der Docker-Compose-App (postgres service, pgvector/pgvector:pg16)
- Redis: Teil der Docker-Compose-App (redis service, redis:7-alpine)
Server
- Host: 46.225.91.159
- SSH Key: /a0/usr/workdir/.ssh/coolify-01-root
Zugaenge
- Web-UI: https://crm.media-on.de/login (admin@media-on.de / Admin123!)
- Forgejo: https://forgejo.media-on.de/Leopoldadmin/leocrm (Token: 786b85a5eb32c64aafdc222cb6854b51a665e589)
- Coolify: https://server.media-on.de (Token: 2|UnMMp2WYbXFJCrOuZ1yqSK96hMooPTAfAJPIXiQc1e47154e)
- Produktions-DB: postgresql+asyncpg://crm_user:86FkF5vJ_qKYgO6Myj0eQ4Dtm3Dyb1ge@postgres:5432/crm_db
- Redis: redis://default:6VJ7pp8afXXZMnx0JztWFk-OYCLwJfX4@redis:6379/0
- SECRET_KEY: DoYnyh_UnvnYphX-qryiaIpQhm8JB39m_xkat9cNmrGpyKSSZvW9jF1tusIUSP5g
- MAIL_ENCRYPTION_KEY: test-mail-encryption-key (AES-256 Fernet Key fuer Mail-Passwort-Verschluesselung, in Coolify als Environment Variable setzen)
Coolify Resources
- Project UUID: mzu7fvhtad82ujgmbsmyvxzm
- Server UUID: lw80w8scs444gwcw084s00s4
- Private Key UUID: rgcsc0048c04csckk8kogk40
Production Resource Recommendations
Die docker-compose.yaml hat Development-Defaults (PostgreSQL 512m, Redis 128m). Fuer Produktion mit 50+ Usern, 100k+ Entities, Agenten, Search und Knowledge muessen die Limits erhoeht werden.
| Service | Development | Production (50+ User) | Begruendung |
|---|---|---|---|
| PostgreSQL RAM | 512m | 1-2GB | pgvector HNSW + FTS + JSONB Snapshots + Outbox + AuditLog |
| PostgreSQL CPU | 1.0 | 2.0 | Vector Search + FTS + normale CRM-Queries |
| PostgreSQL Disk | Named Volume | 50-100GB | Embeddings (768 dim x 100k = ~300MB), JSONB Snapshots, Outbox |
| Redis RAM | 128m | 256-512m | WS Pub/Sub + Caching + Sessions + ARQ + Rate-Limiting |
| Redis CPU | 0.5 | 1.0 | Pub/Sub + Cache + Queue |
| App (FastAPI) RAM | Nicht limitiert | 512m-1GB | WebSocket Connections + Async Tasks |
| App CPU | Nicht limitiert | 1-2 CPUs | API + WS + LLM-Streaming |
| Worker (ARQ) RAM | Nicht limitiert | 256-512m | Background Jobs (Indexierung, Agent-Runs, Extraction) |
| Worker CPU | Nicht limitiert | 1-2 CPUs | LLM-Calls + Embedding + Text-Extraction |
Skalierung bei Bedarf
- Read-Replicas: Bei hohem Lese-Aufkommen (Search, FTS, Vector) koennen Read-Replicas fuer PostgreSQL eingerichtet werden. Schreib-Last (Outbox, EntityHistory, AuditLog) bleibt auf dem Master.
- Mehr Worker: Bei hohem Background-Job-Aufkommen koennen zusaetzliche ARQ-Worker-Container gestartet werden. Queue-Prioritaeten verhindern dass wichtige Jobs hinter langen Index-Jobs warten.
- pgvector auslagern: Bei sehr grossen Datasets (>1M Embeddings) kann pgvector auf einen separaten PostgreSQL-Node ausgelagert werden.
- Redis Cluster: Bei sehr hohem Cache-/Pub/Sub-Aufkommen kann Redis Cluster eingesetzt werden.
LLM-Kosten-Management
- Cost-Tracking: Der zentrale LLM Client (Phase B.1) trackt Kosten pro Call.
- Budget-Limits: Pro Agent (Phase F) und pro Tenant (Phase I).
- Cost-Dashboard: Phase I zeigt LLM-Kosten pro Agent/Workflow/User.
- Alerts: Budget-Alerts bei Ueberschreitung konfigurierbarer Schwellwerte.
ARQ Worker Cron-Jobs
Der crm_worker Service fuehrt folgende Cron-Jobs aus:
| Job | Schedule | Beschreibung |
|---|---|---|
auto_backup_job |
Taeglich 03:00 | Automatisches Backup (ruft scripts/backup.py auf) |
audit_retention_cleanup |
Taeglich 04:00 | Audit-Logs aelter als 365 Tage archivieren/loeschen |
cleanup_expired_trash |
Taeglich 05:00 | Soft-deleted Entities aelter als 90 Tage endgueltig loeschen |
outbox_cleanup |
Stuendlich | Outbox-Eintraege aelter als 30 Tage loeschen |
cleanup_expired_sessions |
Stuendlich | Abgelaufene Sessions aus Redis loeschen |
Container-Entrypoints
| Datei | Service | Funktion |
|---|---|---|
prestart.sh |
crm_app | Alembic-Migrationen -> DB-Role-Passwoerter -> Plugin-Schema-Sync -> Admin-Seed -> uvicorn Start |
worker.sh |
crm_worker | ARQ Worker Start mit Cron-Jobs |
healthcheck.sh |
crm_app | HTTP /api/v1/health oder Redis-Ping |