Skip to content

Last Updated: 2026-05-03 Owner: Ops-Dev Summary: Environment-by-environment deployment guide for local, paper, backtest, and live QuantMatrix rollouts.

QuantMatrix Deployment Guide

This guide explains how to deploy QuantMatrix safely across local, paper, and live environments.

Its purpose is to make deployments: - repeatable - understandable - environment-safe - operationally consistent

This document should be used together with: - the Implementation Specification - the Module Build Checklist Pack - the Operations Runbook - the Live Trading Go-Live Checklist - the Release Change Checklist

1. Deployment Goals

QuantMatrix deployments should: - keep environments clearly separated - avoid accidental live trading - preserve data integrity - preserve auditability - support safe rollback - make health validation easy after each release

2. Supported Environments

Local Development

  • Purpose: engineering work, UI development, local integration
  • Execution: dry-run only
  • Market data: demo feed or non-live feed
  • Risk level: low

Paper Trading

  • Purpose: production-like validation without real capital
  • Execution: paper broker account
  • Market data: real or paper-compatible data source
  • Risk level: moderate operational risk, no real capital

Live Trading

  • Purpose: production trading with real capital
  • Execution: live broker account
  • Market data: approved live market data source
  • Risk level: high

Backtesting

  • Purpose: historical replay and strategy research
  • Execution: simulated only
  • Risk level: no live exposure

3. Environment Separation Rules

These rules are mandatory: - local must never use live execution credentials - backtesting must never be able to route live orders - paper and live credentials must be stored separately - UI must clearly indicate current mode - deployment defaults must favor non-live operation

4. Deployment Artifacts

Typical artifacts may include: - backend application package or container - frontend static assets or bundled UI app - database migrations - environment-specific configuration - health check endpoints - startup scripts or service definitions

For every release, identify: - exact application version - migration version - config version - strategy version(s) - analytics logic version if relevant

5. Prerequisites

Before deployment:

Access

  • [ ] deployment access is available
  • [ ] broker credentials are available to authorized users only
  • [ ] Redis credentials are available
  • [ ] PostgreSQL credentials are available

Readiness

  • [ ] release change checklist completed
  • [ ] production readiness review completed if required
  • [ ] rollback plan documented
  • [ ] migrations reviewed
  • [ ] risk changes reviewed

Operational

  • [ ] operator informed of deployment window
  • [ ] engineer available during release
  • [ ] incident playbook available

6. Configuration Management

Configuration should be separated by environment.

At minimum manage separately: - trading mode - market data provider - execution broker - Redis connection - PostgreSQL connection - API URLs - risk limits - strategy settings - scanner settings - analytics settings

Configuration Rules

  • do not hardcode secrets
  • do not share live secrets into lower environments
  • document all required environment variables
  • review risky defaults before release

7. Local Deployment Guide

Local deployment is for safe development and validation.

Local Goals

  • run UI and backend safely
  • run without live credentials
  • support demo trading flow
  • support module-level testing

Local Checklist

  • [ ] local config file present
  • [ ] dry-run broker enabled
  • [ ] demo or local market data enabled
  • [ ] Redis available if required
  • [ ] PostgreSQL available if required
  • [ ] API starts successfully
  • [ ] UI loads successfully

Local Validation

  • [ ] account summary loads
  • [ ] Momentum Radar loads
  • [ ] watchlist flow works
  • [ ] positions and orders screens load
  • [ ] settings load

8. Paper Trading Deployment Guide

Paper trading is the dress rehearsal for live.

Paper Deployment Goals

  • behave as close to live as possible
  • validate broker connectivity
  • validate reconciliation
  • validate risk logic
  • validate operator workflow

Paper Deployment Checklist

  • [ ] paper broker credentials configured
  • [ ] paper broker endpoint verified
  • [ ] market data source verified
  • [ ] risk limits configured intentionally
  • [ ] UI clearly shows paper mode
  • [ ] alerts active
  • [ ] analytics capture active

Paper Validation

  • [ ] startup flow works
  • [ ] account summary matches broker
  • [ ] order placement works
  • [ ] order cancel works
  • [ ] fills are captured
  • [ ] positions reconcile
  • [ ] end-of-day reconciliation works
  • [ ] emergency halt tested safely

9. Live Deployment Guide

Live deployment should happen only after successful paper validation.

Live Deployment Preconditions

  • [ ] live trading go-live checklist approved
  • [ ] production readiness review approved
  • [ ] operator assigned
  • [ ] engineer on standby
  • [ ] initial capital limits approved
  • [ ] live strategy set approved

Live Deployment Checklist

  • [ ] live broker credentials configured securely
  • [ ] live broker endpoint verified
  • [ ] market data entitlement verified
  • [ ] risk limits reviewed one final time
  • [ ] blocked symbols list loaded
  • [ ] UI clearly indicates live mode
  • [ ] emergency halt visible and verified
  • [ ] reconciliation paths tested recently

First Live Release Rules

  • start with small capital
  • start with limited strategy scope
  • increase exposure only after stable observation
  • halt immediately if execution behavior is ambiguous

10. Database Migration Procedure

When schema changes are included:

Before Migration

  • [ ] migration reviewed
  • [ ] backup plan confirmed if needed
  • [ ] backward compatibility impact reviewed
  • [ ] analytics or reporting impact reviewed

During Migration

  • apply migrations in controlled order
  • verify schema version after apply
  • confirm application compatibility

After Migration

  • [ ] application starts cleanly
  • [ ] health checks pass
  • [ ] critical queries work
  • [ ] reconciliation-related tables operate correctly

11. Deployment Order

Recommended order: 1. confirm release readiness 2. apply configuration updates 3. apply database migrations 4. deploy backend services 5. deploy background workers/services 6. deploy UI 7. run health validation 8. run environment-specific smoke tests 9. monitor closely

If the system is already running: - avoid enabling active trading until health and reconciliation checks pass

12. Post-Deployment Validation

After every deployment:

Core Health

  • [ ] API healthy
  • [ ] Redis healthy
  • [ ] PostgreSQL healthy
  • [ ] market data connection healthy
  • [ ] execution broker connection healthy
  • [ ] risk manager healthy
  • [ ] scanner healthy
  • [ ] strategy allocator healthy
  • [ ] analytics pipeline healthy

Functional Smoke Checks

  • [ ] UI loads
  • [ ] account summary visible
  • [ ] orders screen loads
  • [ ] positions screen loads
  • [ ] risk screen loads
  • [ ] settings screen loads

Trading Safety Checks

  • [ ] mode displayed correctly
  • [ ] no unexpected positions
  • [ ] no unexpected orders
  • [ ] blocked symbols enforced
  • [ ] risk thresholds loaded correctly

13. Rollback Strategy

Every deployment should have a rollback plan.

Rollback may involve: - restoring previous application version - reverting config changes - disabling a feature or strategy - pausing trading - rolling back migrations only if safe and planned

Rollback Rules

  • if execution behavior is unsafe, halt trading first
  • if state is ambiguous, reconcile before resuming
  • do not roll back blindly if migrations changed live data assumptions

Trigger Rollback If

  • new release causes order duplication risk
  • reconciliation breaks
  • risk manager becomes unreliable
  • broker integration becomes unstable
  • critical UI/operator controls disappear or mislead

14. Deployment Monitoring Window

After release, watch closely for: - broker disconnects - rejected orders - position mismatches - delayed fills - stale prices - risk violations - analytics capture failures - UI state mismatches

Recommended monitoring intensity: - local: normal engineering validation - paper: active observation through session - live: heightened observation for first release window and first full session

15. Deployment Failure Handling

If deployment fails: 1. stop further rollout 2. assess whether trading safety is affected 3. halt trading if needed 4. restore previous safe state 5. verify broker state 6. reconcile positions and orders if required 7. document the failure

16. Deployment Documentation Checklist

For every release capture: - release version - deployment date/time - operator and engineer involved - config changes - migration changes - strategy changes - incidents during deployment - rollback used or not - validation results

Recommended path for meaningful changes: 1. local validation 2. automated tests 3. paper deployment 4. paper trading observation 5. production readiness review if needed 6. limited live rollout 7. monitored expansion

18. Companion Documents

Use these together with this guide: - Operations Runbook - Live Trading Go-Live Checklist - Incident Response Playbook - Release Change Checklist