QuantDinger's process split, virtual fills, and the Compose defaults it ships

One backend image, several commands, and two containers that exit first

QuantDinger's v5 backend is organized around runtime boundaries rather than one long-lived server. A single backend image is reused by several containers that each start with a different command. `migration` applies the database schema and exits before application services start; `kafka-init` creates the versioned runtime topics and exits before event consumers start. `backend` handles HTTP, authentication, validation, and durable command submission, and no longer owns long-running trading or scheduler loops. Those loops moved to a `trading-worker` carrying the control, realtime, execution, and grid actor roles, alongside separate strategy dispatcher workers, strategy evaluator workers holding hot bar runtimes, a Kafka audit worker, a scheduler worker, a Celery worker, and Celery beat. Kafka sits between them as the event backbone, with PostgreSQL for state and two Redis instances for cache and durable jobs.

Strategy evolution compares how parameters hold up, not what returns will come

Strategy evolution is the subsystem that most needs reading slowly, because the project states its own limits next to its features. It searches declared tunable parameters using random, grid, or TPE optimization, then validates with bar-count walk-forward and a final blind holdout. Jobs run asynchronously, keep per-strategy history, prune automatically, and report composite scoring, PBO, Deflated Sharpe, block-bootstrap Monte Carlo, and transaction-cost stress tests. The stated purpose is narrow: the results compare how the chosen parameters held up, and they do not forecast future returns. For a reader, that distinction is the whole point. A strong composite score means the neighbourhood of those parameters survived resampling, not that the strategy earns money next quarter.

Signal-only virtual accounts bill 0.05% and 0.05%, and never open a broker connection

Signal-only virtual accounts exist for notification-mode signals that would otherwise stop at an alert. The platform turns them into internal virtual orders, fills, positions, trade records, PnL, and an equity curve, and they never connect to a broker or submit live orders. The cost model is fixed rather than matched to a venue: every fill charges 0.05% commission on executed notional plus 0.05% adverse slippage, and leverage is not charged a second time inside the commission calculation. The consequence for a reader is that the equity curve is a bookkeeping view of signal flow rather than a fill simulation you can calibrate. A strategy whose edge lives inside a tenth of a percent renders as identical here and as something else in production, because there is one flat rate pair to trade against and no venue-specific pricing to adjust.

A default SECRET_KEY stops the stack before any service listens

One missing value is treated as a hard stop. The container will not start if SECRET_KEY is using the default value, which the Compose file calls a security measure to prevent insecure deployments. The same file's usage notes start with a bootstrap script that creates the environment file and random local credentials:

#   1. Create the unified environment file and random local credentials
#      python scripts/bootstrap_env.py
#   2. Set the administrator credentials and any optional integrations in .env
#   3. docker compose up -d --build
#   4. Open http://localhost:8888 (web) or http://localhost:8889 (mobile H5)

The other credentials are left blank instead of defaulted. POSTGRES_PASSWORD, REDIS_PASSWORD, and CELERY_REDIS_PASSWORD are marked as core production credentials, and the template says python scripts/bootstrap_env.py or the one-command installer generates missing values without printing them. GRAFANA_ADMIN_USER defaults to admin while GRAFANA_ADMIN_PASSWORD stays blank, and that pair is needed only with docker-compose.observability.yml. So the first install is a configuration task: leave SECRET_KEY at its default value and nothing comes up.

Cache Redis and job Redis carry different memory ceilings and their own namespace

Two Redis instances run side by side because the workloads evict differently. REDIS_CACHE_MAXMEMORY ships as 128mb and REDIS_JOBS_MAXMEMORY as 512mb, and the cache holds a key namespace of quantdinger:cache:v1. The v5 notes state that cache Redis and durable job Redis use separate instances and separate eviction policies, with Celery handling finite, retryable work while long-lived strategy runtimes stay in the trading worker.

Grid fills ride a 30 second lease with 8 delivery attempts

Grid strategies get their own routing block because their fills must reach the worker that owns the strategy lease. GRID_ACTOR_ROUTING_ENABLED is true by default, events are batched at GRID_ACTOR_BATCH_SIZE=100, each event holds a lease of GRID_ACTOR_EVENT_LEASE_SEC=30, and GRID_ACTOR_MAX_ATTEMPTS=8 caps redelivery. REST reconciliation for grid actors runs locally in the worker that holds the lease. The consequence for someone running a grid strategy is that execution is bound to one owning worker rather than broadcast to the pool. When that worker is unavailable, the lease duration and the retry ceiling, not your strategy logic, decide how the backlog drains, and 8 is the hard limit on how many times a single fill event will be attempted.

Replicas ship at one per runtime role, with no stated threshold for raising them

The first installation is sized for one host. STRATEGY_DISPATCHER_REPLICAS, STRATEGY_EVALUATOR_REPLICAS, and TRADING_WORKER_REPLICAS all arrive set to 1, and the template says to increase them only after load testing, noting that replicas can later be spread across cluster nodes without changing strategy code or Kafka consumer groups. The consequence is direct. With the shipped values, a single evaluator process holds every hot bar runtime and a single trading worker holds control, realtime, execution, and the grid actors. Anyone expecting horizontal redundancy out of the box will not find it, and the configuration gives no load figure that marks the moment those three numbers should move. Sizing stays a judgement call the operator makes on their own hardware.

Image sourcing and registry choice are variables, not a single documented path

Five Compose files ship, and the differences between them are where a first install most often goes wrong. The default file builds the backend from local source under backend_api_python while the frontend and mobile H5 are pulled from GHCR, with tags and paths overridable through FRONTEND_IMAGE, MOBILE_IMAGE, and IMAGE_TAG in a project root .env. Sourcing is a variable too: the backend base image defaults to a Docker Hub mirror for python:3.12, and PYTHON_BASE_IMAGE=python:3.12-slim-bookworm forces the official source, while BUILD_REGION=cn switches the backend build to Aliyun mirrors with fallback and IMAGE_PREFIX redirects the registry globally. docker-compose.production.yml runs backend processes as a non-root user with a read-only root filesystem, dropped capabilities, and resource limits.

Editorial conclusion

QuantDinger fits operators who want strategy code, broker credentials, and deployment on their own machine, and who accept owning a multi-process stack themselves. It does not fit anyone looking for a hosted signal feed. Its own text sets the honest limits: parameter search results do not forecast returns, virtual accounts use one fixed cost pair, and the defaults give one replica per runtime role. Before deploying, confirm SECRET_KEY is not left at its default, run python scripts/bootstrap_env.py to generate the database and Redis passwords, and decide whether the GHCR frontend images and the mirror-based base image match your network.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes