What the backend run establishes
QuantDinger brings research and execution into one platform, but a passing backend test run leaves important deployment questions unanswered.
Our recorded run took place on September 28, 2026, at commit 709521ffd6df8460dc7bfaba0451258b0f1743da, with the Python project under backend_api_python/. The recorded configuration was 3 CPUs, 8 GB of memory, and image ghcr.io/astral-sh/uv:python3.12-bookworm. The install output identifies a Python 3.12.12 environment.
| Stage | Recorded observation | Limit |
|---|---|---|
| Install | Exit 0 after about 55 seconds; 159 dependencies and 559 MB recorded | The retained output includes failed editable-install and wheel-build attempts caused by package discovery of app and migrations. It does not prove the project or a CLI was installed. |
| Build | Exit 0 after about 10 seconds | The retained output is empty and the command is unavailable. It does not establish a Docker image build or a running service. |
| Tests | Exit 0 after about 101 seconds; pytest reports 3,149 passed, 55 skipped, and 44 warnings in 84.40 seconds | The outer step duration and pytest duration measure different scopes. The recorded summary was not reconciled against a complete log for exhaustive unique coverage. |
| Audit | Zero advisories recorded under pip-audit | Coverage is unknown; there is no supported scanned-package count or security assurance. |
The checkout inventory recorded 999 files, approximately 225,105 source lines, 23.3 MB, five CI workflow files, a Dockerfile, and a tests directory. These describe the checkout rather than the resources needed to run the platform.
The retained evidence does not demonstrate a complete Compose deployment, installed-binary checks, a broker order, or a measured trading workload. No new execution was performed for this correction. The packaging errors deserve investigation, but they do not establish that the documented Docker deployment is broken.
Decide whether you want the whole platform
The README describes AI research, Python indicators, Strategy API V2, server-side backtests, paper and live execution, and web, mobile, API, Agent Gateway, and MCP access. It lists crypto integrations alongside IBKR and Alpaca workflows. Those are documented capabilities, not integrations verified by our run.
The backend source uses Apache License 2.0. The README says the desktop and mobile client sources live in separate repositories under their own source-available licenses. Review those terms if your plans include modifying or redistributing the clients.
For a Python team that wants research and paper execution in one environment, the breadth may be useful. It also creates operational work: persistent state, worker ownership, job recovery, credentials, and monitoring all need attention. A team that only needs crypto bot operation or model experiments should compare the narrower workflows below before adopting the stack.
Deployment instructions have changed since the measured commit
The README at 709521f documents separate root and backend environment files. The supplied current README instead documents a unified project-root .env, initialized through its bootstrap script. It says bootstrap generates independent PostgreSQL, session-signing, and credential-encryption secrets while preserving existing values during upgrades.
The current runtime topology also includes Kafka, strategy dispatcher and evaluator workers, and an independent Kafka audit worker, alongside PostgreSQL, separate cache and job Redis instances, trading workers, scheduling, and Celery. Use instructions that match your checkout rather than combining the older environment layout with current Compose definitions.
For prebuilt images, the README requires Docker with Compose v2 and says the installer asks for administrator credentials, generates secrets, downloads images, and starts the stack. Our backend run did not verify that route. The documented production requirements include TLS termination, private database and queue access, PostgreSQL and durable job-Redis backups, and worker readiness checks. Prometheus, Grafana, and Alertmanager remain optional.
Release v5.0.18 points to 366ea33. Our measured commit is 709521f; the run should not be described as a test of that release tag.
The cited calculation issues are closed
Issue 218 reported fixed four-decimal OHLC rounding that could lose precision for some exchange symbols. GitHub records it as closed as completed through #224 on August 27, 2026.
Issue 219 reported a hardcoded crypto lot size of 1e-8 and residual quantities that could block simulated re-entry. GitHub records it as closed as completed in ef932ad on August 27, 2026.
Issue 216 reported low reward-to-risk plans without a warning in a v5.0.17 deployment. The maintainer's August 27 response says the fix recalculates directional reward-to-risk after finalizing the plan, returns a warning below 1, and prioritizes valid model-provided levels without forcing a more distant target. The issue is closed as completed.
Issue 217 reported 427 SELL decisions among 518 analyses from six symbols over four days on v5.0.17. The maintainer's August 27 response says the asymmetric SELL prompt was removed and trend-related confirmation and monitoring were added. That issue is also closed as completed. The reporter's sample is historical evidence from that deployment, not our benchmark or a measured decision distribution for the current platform.
These closure records establish issue status and reported remediation. We did not independently replay the original reproductions. Before relying on a backtest, compare stored candles, quantity steps, minimum notional, fees, and fill assumptions with the intended venue. That remains useful validation even after a reported defect is closed.
Agent authorization and AI decisions have different limits
The README says MCP clients use approved tools through /api/agent/v1 without receiving broker credentials or administrator JWTs. It documents hashed, scoped, rate-limited, audit-logged agent tokens. Live agent trading requires trading scope, paper_only=false, server-side enablement, and operator limits and allowlists. Our run does not independently validate those controls in a deployment.
The optional AI entry filter has a separate policy. The current README says rejected entries do not reach the exchange, while exits and emergency actions bypass the filter. If Jev is unavailable, the platform tries its configured LLM; if no AI provider is available, the order is allowed and the fail-open result is logged. The documented first version excludes grid, DCA, and martingale runtimes.
An operator who requires an AI outage to block entries must account for that policy. Keep numerical risk limits and permissions explicit, and begin with one provider, one paper account, and one strategy whose inputs and simulated fills you can inspect.
How to read the scores
These are editorial suitability ratings, not measured reliability percentages. On the five-point scale, 1 means substantial obstacles or very little supporting evidence; 2 means significant burden or limited evidence; 3 means useful documented support with material validation gaps; 4 requires strong evidence across the relevant workflow; and 5 requires broad verification with few material gaps. A low score caused by limited evidence does not establish poor product quality.
Setup ease is 2 because the documented platform has several services and the install record contains packaging errors. Documentation is 3 because the README explains architecture, deployment, and authorization, but instructions differ between the measured commit and current source and were not verified end to end. Community is 2 because the supplied issue responses show maintainer engagement, while adoption, support response times, and contributor breadth remain unmeasured. Maturity is 3 because the backend run and completed issue work provide useful evidence, with production execution and venue behavior still outside the measured scope.
Alternatives by task
Freqtrade documents crypto bot operation, backtesting, dry runs, strategy optimization, and exchange trading. Compare it when operating a crypto strategy is your main requirement. Its README also advises starting in dry-run mode.
Qlib documents a machine-learning pipeline covering data processing, training, backtesting, and broader investment workflows, including order execution. Compare it when research components and customized model workflows matter most. Neither alternative was run in this evaluation.
For QuantDinger, the useful next step is a version-pinned paper deployment followed by venue-specific checks. The recorded pytest result supports further evaluation; it does not establish profitable signals, realistic execution, or a production-ready installation.