QuantDinger README

The project's README from github.com/OpenByteInc/QuantDinger. As one markdown file: README.md.

QuantDinger logo

QuantDinger

Open-source AI Trading OS

Turn trading ideas into Python strategies, backtests, paper trading, live execution, and monitoring — all in one self-hosted stack.

QuantDinger is a product of Open Byte Inc.

AI research → Strategy code → Backtest → Paper/Live execution → Monitoring

English · 简体中文 · API · AI Agents & MCP

Live App · Website · Video Demo · Official Support Email

Telegram Discord YouTube X @QuantDinger_EN

Apache 2.0 Python 3.12 PostgreSQL 18 Redis 8 Docker Compose Latest release

SUPPORTED BY

Atlas Cloud      Amazon Web Services

QuantDinger can submit real orders when live trading is explicitly enabled. Start with paper trading, use restricted API keys, and review the risk and compliance requirements for your jurisdiction. This project does not provide investment advice.

What QuantDinger is

QuantDinger is an open-source AI Trading OS for independent traders, Python strategy authors, and small teams. Its local-first, self-hosted design keeps market data, strategy code, broker credentials, and deployment under the operator's control.

The project combines:

It is not a black-box signal service. Strategy code, risk settings, credentials, and deployment remain under the operator's control.

What changed in v5

The v5 backend is organized around explicit runtime and operational boundaries:

The source version is declared in VERSION. Git release tags use the same semantic version with a leading v, for example v5.0.1.

Architecture

QuantDinger v5 architecture covering clients, Agent Gateway, core platform, workers, infrastructure, observability, and the closed-loop trading workflow

The editable source is available as architecture-v5.svg.

The diagram above shows the complete product and process architecture. The runtime topology below focuses on container-to-container ownership and data flow.

flowchart TB
    C["Web / Mobile / API / MCP clients"]
    FE["Nginx frontend services"]
    API["Flask + Gunicorn API"]
    PG[("PostgreSQL")]
    CACHE[("Redis cache")]
    JOBS[("Redis jobs")]
    TW["Trading worker"]
    SW["Scheduler worker"]
    CW["Celery worker"]
    BEAT["Celery beat"]
    PROM["Prometheus"]
    GRAF["Grafana"]
    ALERT["Alertmanager"]

    C --> FE --> API
    API --> PG
    API --> CACHE
    API -->|"durable commands"| PG
    TW -->|"leases, orders, heartbeats"| PG
    SW -->|"schedules, monitoring, heartbeats"| PG
    API -->|"finite async jobs"| JOBS
    BEAT --> JOBS --> CW
    CW --> PG
    API -. metrics .-> PROM
    PG -. exporter .-> PROM
    CACHE -. exporter .-> PROM
    JOBS -. exporter .-> PROM
    PROM --> GRAF
    PROM --> ALERT

One backend image is reused by several containers with different commands:

Process Responsibility
migration Applies the database schema and exits before application services start.
backend Handles HTTP, authentication, validation, and durable command submission.
trading-worker Owns strategy runtimes, pending orders, broker sessions, and reconciliation.
scheduler-worker Runs portfolio, deployment, payment, and signal schedules.
celery-worker Executes finite AI, backtest, experiment, report, and maintenance jobs.
celery-beat Dispatches periodic Celery tasks.

See Backend process roles, architecture, and concurrency model for the ownership rules.

Quick start

Option A: prebuilt images

Prerequisites: Docker with Compose v2. Node.js and a local Python environment are not required.

Linux or macOS:

curl -fsSL https://raw.githubusercontent.com/OpenByteInc/QuantDinger/main/install.sh | bash

Windows PowerShell:

irm https://raw.githubusercontent.com/OpenByteInc/QuantDinger/main/install.ps1 | iex

The installer asks for the initial administrator credentials, generates the required secrets, downloads the GHCR Compose stack, and starts it.

Open:

Docker administrator and settings notes

Detailed guides: English | 中文

On a fresh database, the backend creates the initial administrator from ADMIN_USER, ADMIN_PASSWORD, and optional ADMIN_EMAIL. Passwords are stored as hashes, never as plaintext. An existing PostgreSQL volume is not overwritten: the backend only replaces the untouched legacy quantdinger / 123456 administrator when a non-default administrator is explicitly configured. It never overwrites an account whose password was already changed, and it refuses to promote an existing account that already uses the requested username.

Manual Docker deployments retain quantdinger / 123456 only for backward compatibility when the administrator variables are left at their defaults. This credential is not suitable for an internet-facing deployment; change it before first start or immediately after the first login. The one-command installer does not accept 123456 as the chosen password.

The Settings UI writes runtime configuration to /app/.env. In the GHCR stack this is the host backend.env; in a source deployment it is backend_api_python/.env. Current backend images automatically give runtime UID 10001 ownership and keep mode 600. Do not use chmod 755 or recursive 777: these files contain passwords and API keys, and 755 still does not grant write access to UID 10001 when root owns the file.

Verify write access with:

docker compose exec -u 10001:10001 -T backend \
  sh -c 'test -w /app/.env && echo writable=yes || echo writable=no'

The hardened production override intentionally mounts /app/.env read-only. When using docker-compose.production.yml, manage configuration on the host and recreate the services instead of saving it from the Settings UI. See the English guide or 中文指南 for legacy-image recovery and rootless/NFS notes.

Option B: source checkout

git clone https://github.com/OpenByteInc/QuantDinger.git
cd QuantDinger
cp backend_api_python/env.example backend_api_python/.env
cp .env.example .env

Before the first start, replace the example values in both environment files:

File Required production values
backend_api_python/.env SECRET_KEY, CREDENTIAL_ENCRYPTION_KEY, ADMIN_USER, ADMIN_PASSWORD
.env POSTGRES_PASSWORD, REDIS_PASSWORD, CELERY_REDIS_PASSWORD, GRAFANA_ADMIN_PASSWORD

Generate independent secrets with:

python -c "import secrets; print(secrets.token_hex(32))"

Start the core stack from local backend source:

docker compose up -d --build
docker compose ps

The base stack does not start Prometheus, Grafana, or Alertmanager. This keeps the default open-source installation smaller.

For detailed installation paths, Windows notes, China mirror settings, and PostgreSQL migration guidance, see Installation troubleshooting and the cloud deployment guide.

Production deployment

Validate secrets before starting a production stack:

python backend_api_python/scripts/check_production_config.py \
  --env-file .env \
  --env-file backend_api_python/.env

Start the hardened runtime with optional observability:

docker compose \
  -f docker-compose.yml \
  -f docker-compose.production.yml \
  -f docker-compose.observability.yml \
  up -d --build

Omit docker-compose.observability.yml when the host is resource-constrained or monitoring is provided externally.

Production rules:

The full checklist is in Production hardening.

Local endpoints

All published ports bind to loopback by default.

Service Default URL Purpose
Web http://127.0.0.1:8888 Desktop web client and same-origin API proxy.
Mobile H5 http://127.0.0.1:8889 Mobile web client and same-origin API proxy.
Backend http://127.0.0.1:5000 Direct API access and health endpoints.
Grafana http://127.0.0.1:3000 Dashboards; available only with the observability overlay.
Prometheus http://127.0.0.1:9090 Metrics storage and queries; optional.
Alertmanager http://127.0.0.1:9093 Alert grouping, silencing, and delivery; optional.

Container-only ports such as the job Redis and exporters are not published to the host.

Observability

The monitoring stack is optional by design:

Start it for local diagnostics without the production overlay:

docker compose \
  -f docker-compose.yml \
  -f docker-compose.observability.yml \
  up -d

Monitoring services stay on 127.0.0.1. Use a VPN, SSH tunnel, or authenticated reverse proxy for remote administration. See Observability for dashboards, alerts, retention, and receiver configuration.

Security model

Report vulnerabilities privately according to SECURITY.md. Do not include credentials, account data, or exploitable details in public issues.

Strategy and integration surfaces

Area Current surface
Indicators Python chart overlays, markers, bands, and signals.
Strategies Strategy API V2 intents, sizing, risk, backtests, and live runtime.
Crypto Binance, OKX, Bitget, Bybit, Gate, HTX, and adapter extensions.
Traditional brokers IBKR and Alpaca workflows.
AI providers OpenRouter, OpenAI-compatible APIs, Google, DeepSeek, Grok, MiniMax, and custom endpoints.
Automation Human API, Agent Gateway, MCP server, Celery jobs, schedules, and notifications.

Start with the Indicator guide, Strategy guide, and Extension guide.

AI agents and MCP

The Agent Gateway is exposed under /api/agent/v1. The included MCP server lets clients such as Cursor, Claude Code, and Codex call approved tools without receiving broker credentials or administrator JWTs.

Live trading through an agent requires all of the following:

  1. a token with trading scope;
  2. paper_only=false on that token;
  3. AGENT_LIVE_TRADING_ENABLED=true on the server;
  4. operator-configured limits and allowlists.

See MCP setup, Agent quick start, and the Agent OpenAPI document.

Development

Backend development uses Python 3.12:

cd backend_api_python
python -m venv .venv
python -m pip install -r requirements-dev.txt
python -m pytest -m "not integration and not stress" --ignore=tests/release_gate -q
ruff check app scripts tests

Useful repository checks:

python scripts/check_version.py
python scripts/check_mojibake.py
docker compose -f docker-compose.yml config -q
docker compose -f docker-compose.yml -f docker-compose.production.yml -f docker-compose.observability.yml config -q

API changes should follow API conventions, update the OpenAPI artifact when required, and pass the compatibility workflow.

Repository layout

This repository contains the backend, worker processes, deployment definitions, operations configuration, documentation, and MCP server. The desktop and mobile client source code live in separate repositories; this repository consumes their published images in the Compose stacks.

QuantDinger/
|-- .github/workflows/                 CI, security, compatibility, and release checks
|-- backend_api_python/                Backend application and all backend processes
|   |-- app/
|   |   |-- __init__.py                Flask application factory and core wiring
|   |   |-- startup.py                 Process-aware startup hooks and service singletons
|   |   |-- celery_app.py              Celery application and task registration
|   |   |-- commands/                  Migration, scheduler, trading, and health entrypoints
|   |   |-- config/                    Environment-backed database, Redis, and provider config
|   |   |-- routes/                    Human HTTP API route facades
|   |   |   `-- agent_v1/              Scoped Agent Gateway API under /api/agent/v1
|   |   |-- openapi/                   OpenAPI schemas, tags, registration, and export support
|   |   |-- services/                  Domain workflows and third-party integrations
|   |   |   |-- backtest_engine/       Backtest execution components
|   |   |   |-- live_trading/          Normalized crypto exchange adapters
|   |   |   |-- alpaca_trading/        Alpaca broker integration
|   |   |   |-- ibkr_trading/          Interactive Brokers integration
|   |   |   |-- strategy_runtime/      Strategy signals, intents, execution, and state
|   |   |   `-- strategy_v2/           Versioned strategy contracts and runtime services
|   |   |-- data_sources/              Raw market-data source adapters
|   |   |-- data_providers/            Aggregated market, macro, news, and sentiment providers
|   |   |-- markets/                   Market and symbol normalization
|   |   |-- tasks/                     Finite, retryable Celery jobs
|   |   |-- workers/                   Long-lived worker process shells
|   |   |-- runtime/                   Process-role and ownership helpers
|   |   |-- observability/             Request context, metrics, and HTTP instrumentation
|   |   `-- utils/                     Shared low-level database, cache, auth, and logging helpers
|   |-- migrations/                    PostgreSQL schema and seed migrations
|   |-- scripts/                       Backend maintenance and validation commands
|   |-- tests/                         Unit, contract, integration, and release-gate tests
|   |-- run.py                         Local Flask and Gunicorn application entrypoint
|   |-- Dockerfile                     Shared image for API and worker containers
|   `-- docker-entrypoint.sh           Container command dispatcher
|-- docs/
|   |-- architecture/                  Boundaries, concurrency, API, and extension design
|   |-- deployme

QuantDinger (OpenByteInc/QuantDinger)

Searching Database…

Что это такое?QuantDinger — это открытая торговая ОС с ИИ, которую можно развернуть на собственном сервере. Она помогает исследовать торговые идеи с помощью ИИ, писать Python-стратегии через Strategy API, тестировать их на бэктесте на сервере и запускать торговлю в режиме paper или реальную торговлю на криптобиржах и у традиционных брокеров. Доступ возможен через веб, мобильное приложение, API и MCP.
Это торговый бот или полноценная платформа для самостоятельного развёртывания?Это полноценная платформа для самостоятельного развёртывания. Она состоит из отдельных процессов: backend, trading-worker, scheduler-worker и Celery, которые работают поверх PostgreSQL и Redis. Это не один скрипт бота и не «чёрный ящик» с торговыми сигналами.
Как это запустить?Самый быстрый путь — однокомандный установщик для Linux/macOS или Windows PowerShell. Он загружает стек Docker Compose из GHCR, генерирует необходимые секреты и запускает систему. Также можно взять исходный код и запустить Docker Compose со своими секретами в файле .env.
Нужно ли сначала установить Python или Node.js?Нет. Для варианта с готовыми образами достаточно Docker с Compose v2. Python 3.12 нужен только в том случае, если вы собираете проект из исходников для разработки backend.
Может ли он сразу совершать сделки на реальные деньги?Нет, торговля через агентов по умолчанию работает только в режиме paper. Для перехода на реальные сделки нужны токен с областью действия trading, параметр paperonly=false, серверная настройка AGENTLIVETRADINGENABLED=true и лимиты, заданные оператором.
Как защищены мои учётные данные брокера и API-ключи?Учётные данные брокера и секреты MFA шифруются с помощью постоянного ключа CREDENTIALENCRYPTIONKEY. Токены агентов хранятся в виде хешей, имеют ограниченную область действия и лимит запросов, а все действия записываются в журнал аудита. Доступ к файлам .env во время работы ограничен пользователем с UID, отличным от root.
На каких биржах и у каких брокеров можно торговать?Для криптовалют поддерживаются Binance, OKX, Bitget, Bybit, Gate, HTX и расширения-адаптеры. Традиционные рынки подключаются через рабочие процессы с брокерами IBKR и Alpaca.
Какие ИИ-провайдеры можно использовать для исследований и стратегий?QuantDinger поддерживает OpenRouter, API, совместимые с OpenAI, Google, DeepSeek, Grok, MiniMax, а также собственные эндпоинты для мультипровайдерного ИИ-анализа рынка.
Могут ли агенты для программирования, например Claude Code или Cursor, управлять им?Да. Встроенный MCP-сервер и Agent Gateway по адресу /api/agent/v1 позволяют таким инструментам, как Cursor, Claude Code и Codex, вызывать одобренные торговые функции. При этом они не получают учётных данных брокера и админские JWT.
Можно ли превратить это в собственный торговый SaaS?Да. В комплекте есть управление пользователями с поддержкой нескольких арендаторов (мультитенантность), биллинг, платежи и расчёты. Оператор может запустить собственный брендированный торговый SaaS на основе этого стека.
Size
84.5 MB
Stars
12.9K
Age
9mo
Commits · 90 Days