Running the platform

The four hosts

The bot runs on its own. The dashboard and the API are what a customer touches.

Prerequisites

.NET 10 SDK. Nothing else — the database is SQLite, created on first run.

Two credentials are yours to supply, and both are deliberately empty in appsettings.json:

Keep them out of the repository. In development:

# from QuantMarketEngine/src/QuantMarketEngine.TelegramBot
dotnet user-secrets set "AlphaVantage:ApiKey" "YOUR_KEY"
dotnet user-secrets set "Telegram:BotToken"   "YOUR_TOKEN"

In production, environment variables: AlphaVantage__ApiKey, Telegram__BotToken.

What you have to sign up for, and what it costs

Two external accounts. Both have a free tier this engine fits inside, and you can evaluate the whole platform without either.

Market data — required for live prices

Telegram — optional

Only if you want the publishing channel. A bot token is free from @BotFather inside Telegram itself, in about a minute. Without it the engine runs completely normally — it writes its reports to disk and to the static site, and simply does not publish to Telegram.

Running with no account at all

CsvFileProvider ships with the repository along with the historical bars, so the engine runs, produces reports and can be measured end to end with no registration anywhere. That is how the calibration studies in this project were produced — every one of them states "zero provider calls". Use it to evaluate the engine before signing up for anything.

The whole monthly bill

Stripe has no monthly fee — it takes a percentage per transaction. Outbound email has free tiers of a few hundred messages a day, far more than password resets need.

Choosing which instruments to cover

EUR/USD, gold and silver are a configuration, not a design. Nothing in the analysis is written for a particular instrument — the layers receive candles and a symbol code, and never ask what the code means.

Where the list lives

In the database, managed from the web interface — /admin/symbols in the dashboard. Add an instrument, pause one, resume one; the change takes effect on the next scheduled run with nothing to restart and no file to edit.

Who can reach that page is Admin:Emails in the dashboard's configuration. Leave it empty and nobody has access, including you. That is deliberate: an empty list read as "no restriction" would open the page to every subscriber on a deployment that simply forgot the setting.

Telegram:ActiveSymbols is now only a seed. On a first run against an empty database its contents become the initial rows; after that the table is authoritative and the setting is not consulted again — so switching an instrument off in the browser is not undone by the next restart.

A one-off run can still target a single instrument regardless of the list:

dotnet run -- report GBPUSD 1D

Remember the cost: 4 provider calls per symbol per report. On a 25-a-day free allowance, three symbols is comfortable and six is the ceiling.

Adding one properly

dotnet run -- seedhistory   # full daily history, every active symbol
dotnet run -- backfill      # walk-forward scoring — fills the calibration cards

What a new instrument does not have on day one

A calibration record. The engine will not claim one it has not earned — the calibration page prints "sample too small" until 20 scored outcomes exist for that symbol, and the confidence figure falls back to an absolute reading rather than a rank inside a history it does not yet have. backfill shortens this by scoring the past in one pass; after that the record accrues daily.

Using a different data provider

Nothing ties this engine to AlphaVantage. The analysis layers never see a vendor — they ask for candles through an interface, and the vendor sits behind it. Two implementations already exist, so the pattern is not theoretical: AlphaVantageProvider (HTTP) and CsvFileProvider (files on disk).

What a provider has to supply

Two interfaces, in Domain/Interfaces, deliberately small:

public interface IMarketDataProvider
{
    Task<IReadOnlyList<MarketSnapshot>> FetchAsync(
        string symbol, string timeframe, CancellationToken ct = default);
}

public interface IHistoricalMarketDataProvider
{
    Task<IReadOnlyList<MarketSnapshot>> FetchHistoryAsync(
        string symbol, string timeframe, CancellationToken ct = default);
}

They are separate on purpose: the first fetches only the recent window the live analysis needs, the second returns as much history as the source will give for the walk-forward backtest. One class may implement both, which is what both existing providers do.

And a MarketSnapshot is what you would expect — nothing vendor-shaped in it:

The three steps

services.AddScoped<IMarketDataProvider, MyVendorProvider>();
services.AddScoped<IHistoricalMarketDataProvider, MyVendorProvider>();

That is the whole change. No analysis layer, no renderer, no report and no test touches a vendor name.

If you have your own data

CsvFileProvider already reads OHLC from files on disk. If you have history in CSV — from a broker export, a terminal, or a vendor you already pay for — you may not need a new class at all: point the CSV data directory at your files and the engine runs on them. That is exactly how every calibration study in this project was produced.

The one thing that catches people

This repository already wires them together by relative path:

That works when the three run from their project folders on one machine, which is the development layout. On a server, set all three to one absolute path — a volume the containers share, or a path on the host:

ConnectionStrings__Quant=Data Source=/data/quant.db

If you move to PostgreSQL, the Npgsql provider is already referenced.

Running it locally

Three terminals, or run whichever you need.

The engine — generates today's report for every active symbol:

# from QuantMarketEngine/src/QuantMarketEngine.TelegramBot
dotnet run -- report

The dashboard — the site a subscriber signs into:

dotnet run --project QuantMarketEngine/src/QuantMarketEngine.Dashboard --urls http://localhost:5199

The API — what an X-Api-Key calls:

dotnet run --project QuantMarketEngine/src/QuantMarketEngine.API --urls http://localhost:5006

Open http://localhost:5199, create an account, and you land on the free Observer plan.

Migrations and seeding

On a single node you do nothing. Database:MigrateOnStartup defaults to true, so the dashboard and the API migrate and seed on boot.

On more than one node, turn that off — otherwise every instance races Migrate() against the same database at start-up. Set Database__MigrateOnStartup=false on the nodes and run the migrator once as a deploy step:

dotnet run --project QuantMarketEngine/src/QuantMarketEngine.Migrator

It is idempotent and safe to re-run.

Seeding creates the three plans the pricing page renders from — Observer $0, Analyst $49/mo, Desk $79/mo — with their entitlements. Change a price in SaasPlanSeeder and it reconciles on the next boot; the pricing page and the entitlement checks both read the same catalogue, so they cannot disagree.

Deploying

Four Dockerfiles are in the repository.

Both web hosts expose /health/live (is the process up) and /health/ready (can it reach the database) — point your orchestrator's liveness and readiness probes at those respectively.

A minimal deployment is: run the migrator once, then the dashboard, the API and the bot, all three with ConnectionStrings__Quant pointing at one shared volume.

What is honestly incomplete

Where to read next