QuantDinger
Open-source AI Trading OS, agent trading, and vibe trading, with Jev System One integration. Research, build Python strategies, backtest, and paper/live trade across crypto, stocks, and forex. Launch your own multi-tenant trading SaaS with built-in user management, billing, payments, and settlement.
Install / Use
claude mcp add OpenByteInc -- npx -y github:OpenByteInc/QuantDingerIf the server publishes to npm under a different name, use that package instead — check the repo README.
MCP Server
Model Context Protocol server
Quality Score
Category
Finance & AccountingSupported Platforms
Skill content
View source on GitHubQuantDinger 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:
- multi-provider AI market research and analysis;
- Python indicators and Strategy API V2 development;
- server-side backtesting and experiment workflows;
- paper and live execution across crypto exchanges and traditional brokers;
- web, mobile H5, human API, Agent Gateway, and MCP access;
- PostgreSQL-backed state, durable workers, audit logs, and optional monitoring.
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 HTTP API no longer owns long-running trading or scheduler loops;
- trading, scheduling, Celery jobs, and migrations run as separate processes;
- Celery handles finite, retryable work while long-lived strategy runtimes stay in the trading worker;
- cache Redis and durable job Redis use separate instances and eviction policies;
- high-risk API contracts are represented in OpenAPI and protected by tests;
- JSON logs, request IDs, Prometheus metrics, dashboards, and alert rules are available through an optional observability overlay;
- the production overlay runs backend processes as a non-root user with a read-only root filesystem, dropped capabilities, and resource limits;
- CI checks syntax, lint, tests, release gates, Compose files, dependencies, source security, secrets, API compatibility, version drift, and text encoding.
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
<p align="center"> <img src="docs/screenshots/architecture-v5.png" alt="QuantDinger v5 architecture covering clients, Agent Gateway, core platform, workers, infrastructure, observability, and the closed-loop trading workflow" width="100%"> </p> <p align="center"><sub>The editable source is available as <a href="docs/screenshots/architecture-v5.svg">architecture-v5.svg</a>.</sub></p>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:
- Web: http://127.0.0.1:8888
- Mobile H5: http://127.0.0.1:8889
- API health: http://127.0.0.1:5000/api/health
Docker administrator and settings notes
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
Truncated for display — read the full file on GitHub.
Related Skills
Agent-Reach
84.2kGive your AI agent eyes to see the entire internet. Read & search Twitter, Reddit, YouTube, GitHub, Bilibili, XiaoHongShu — one CLI, zero API fees.
headroom
73.4kCompress tool outputs, logs, files, and RAG chunks before they reach the LLM. 20% fewer tokens for coding agents, 60-95% fewer tokens for JSON, same answers. Library, proxy, MCP server.
ruflo
73.0k🌊 The original agent harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, federation, vector RAG integration, and native Claude Code / Codex / Hermes and many more Integrated
CowAgent
47.1kOpen-source super AI assistant & Agent Harness. Plans tasks, runs tools and skills, self-evolves with memory and knowledge. Multi-agent, multi-model, multi-channel. Lightweight, extensible, one-line install.
