Files
momentum-system/deploy
momentum devandClaude Opus 5.5 b3f023f6e2 feat: nightly off-box backup of the live DB, and phone alerts from the daily report
The live (Tradier) stack has no backup service. Only the paper stack backs up its
own DB, so the 80-trade test's whole record lived only on the TrueNAS pool.
- deploy/backup_live_db.py, run by Task Scheduler "Momentum\LiveDbBackup" at 20:40 ET
  nightly: pg_dump -Fc (PostgreSQL 18.6 client) of the live DB to
  C:\Users\Admin\momentum-backups. It is verified with pg_restore --list (the events
  and config_overrides data must be present), keeps the newest 7, and writes
  status.json. A broken dump is deleted rather than kept.
- research/daily_report.py alerts when the last backup failed or is more than 36 h
  old. When there are alerts it sends them to Telegram, using the stack's own sender
  and the credentials in .env. --no-telegram suppresses that for dry runs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B3PXXn2tHBzdv6rYtGPz86
2026-10-02 21:46:05 -05:00
..

Deploying Momentum

Three supported shapes, one image/codebase. Pick by where it runs:

Mode Status Use when Docs
Docker Compose ✅ canonical (production since 2026-07-09) Any always-on Linux host; TrueNAS SCALE docker/README.md, docker-compose.yml (root), docker/truenas-compose.yml
Local (systemd) ✅ maintained Development machine, WSL, bare metal without Docker systemd/README.md + unit templates in deploy/systemd/
Helm / Kubernetes 🚧 planned refresh Future k8s hosting helm/ — the chart predates the 2026-07 architecture; starting point, not deployable

Docker Compose (canonical)

The root docker-compose.yml runs the full stack self-contained: postgres 18, trading loop, dashboard (:8765), admin panel (:8767), telegram bot, transcripts pipeline, nightly scheduler, on-demand jobs, optional Grafana. The image is published to docker.io/fez5587/momentum-app and ghcr.io/fez5587/momentum-app by CI on every master push.

For TrueNAS SCALE use docker/truenas-compose.yml (pull-only, dataset host paths, inline env). Read the gotchas in docker/README.md before editing the YAML — anchor expansion, per-service env, and path case-sensitivity have each caused an outage.

Local (systemd user services)

The original deployment: unit templates in deploy/systemd/ running a git checkout + venv, config from .env. Still the best loop for development — tests, backtests, and research scripts run here. Keep the units disabled while the compose stack owns production: two loops against one Alpaca account create duplicate orders.

Helm (future)

deploy/helm/ holds the original chart (single app deployment + CronJobs). It predates the service split, the session gate, and the env-flag inventory; the refresh is tracked in GitHub issues. Until then, compose is the way.

Config in all modes

  • .env.example (committed, sanitized) is the full variable inventory and says which layer each belongs in.
  • Behavior flags that MUST be set explicitly in any deployment — silent defaults bite: TRADING_AUTO_APPROVE=1 (else entries queue for manual approval), ALPACA_DATA_FEED=sip, OLLAMA_ENABLED=true (catalyst engine), FMP_API_KEY (float cache). TRADING_SESSION_ONLY defaults ON in deployed configs (bars after-hours entries).
  • Runtime overrides: the admin panel writes data/overrides.env, which every service loads over its baked env at boot (runtime/env_overrides.py).