Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/backtest-kit/backtest-kit-minio-s3-docker/llms.txt

Use this file to discover all available pages before exploring further.

backtest-kit-minio-s3-docker is a drop-in persistence layer for the backtest-kit algo-trading framework that replaces the default file-based ./dump/ storage with MinIO (S3) as the source of truth and Redis as a time-ordered index, packaged with docker-compose for one-command infrastructure deploys. It ships 16 custom IPersist*Instance adapters that fulfill the full backtest-kit persistence contract — strategy code, runners, and the CLI entrypoint are completely unchanged; only the storage layer is swapped out beneath them.

The Three Components

The project composes three layers that each play a distinct role:
  • backtest-kit — the core algo-trading framework that defines the IPersist*Instance contract, the Backtest, Live, and Paper runners, and the @backtest-kit/cli entrypoint. None of its internals are modified.
  • MinIO (S3) — serves as the primary source of truth. Every persisted entity is stored as a JSON object inside a single backtest-kit bucket. MinIO provides strong read-after-write consistency for single objects, S3-compatible tooling (mc mirror, lifecycle rules, versioning), and an administrative web console. It exposes the S3 API on port 9000 and a management UI on port 9001.
  • Redis — maintains a time-ordered index for the three entities that require newest-first listings: Log, Notification, and Storage. Rather than walking an entire S3 bucket, Redis stores one SET per minute (keyed by aligned timestamp), allowing listNewest(limit) to walk backwards in time with a handful of pipeline RTTs — completely independent of how many total objects the bucket contains.

Choosing the Right Persistence Variant

Not every project needs the same persistence backend. The table below shows the practical trade-offs between the three available options:
Default file ./dump/MinIO + Redis (this project)@backtest-kit/mongo / @backtest-kit/pg
InfrastructureNone2 containersDatabase + Redis cache
Source of truthJSON files on local diskJSON objects in S3 bucketRows / documents
Durability & opsSingle host, manual backupS3 semantics: versioning, replication, mc mirror, lifecycleDB tooling: dumps, replicas
Newest-first listingsDirectory scanRedis minute-index, O(limit)ORDER BY … LIMIT, O(log n)
Point reads (candles)fs.readFile1 GET ≈ 1–3 msB-tree lookup ≈ 0.1–1 ms
Sweet spotLocal runs, CIFat JSON snapshots, cheap unbounded archive, S3-native infraHundreds of millions of candles, ad-hoc SQL/aggregation
Pick this variant when you want S3-grade durability and zero schema management but a full DBMS would be overkill — for example when your infrastructure already runs on S3-compatible object storage, you want mc mirror for off-site replication, or you prefer keeping everything in flat JSON without managing migrations.
If your candle dataset grows into the hundreds of millions of rows, the @backtest-kit/pg or @backtest-kit/mongo packages are the better choice. B-tree index lookups and ORDER BY … LIMIT queries outperform S3 prefix listing at that scale, and both packages include Redis caching to accelerate repeated reads.

The 16 Persist Adapters

The project ships one adapter for each IPersist*Instance interface defined by backtest-kit. All 16 live inside a single MinIO bucket (backtest-kit), each assigned its own root folder. Adapters that require newest-first ordering additionally maintain a Redis minute-index via a corresponding *ConnectionService.
AdapterFolderPurpose
Candlecandle-items/OHLCV cache; immutable inserts
Signalsignal-items/Live signal state per context
Scheduleschedule-items/Pending scheduled signal
Strategystrategy-items/Deferred commit queue snapshot
Riskrisk-items/Active risk positions snapshot
Partialpartial-items/Partial profit/loss levels per signal
Breakevenbreakeven-items/Breakeven reached flag
Storagestorage-items/Closed/opened signal log per mode
Notificationnotification-items/Event notifications (Redis-indexed)
Loglog-items/Strategy log entries (Redis-indexed)
Measuremeasure-items/LLM/API response cache
Intervalinterval-items/Once-per-interval markers
Memorymemory-items/Per-signal memory store
Recentrecent-items/Last public signal per context
Statestate-items/Per-signal state buckets
Sessionsession-items/One session per running strategy
For detailed adapter contracts, configuration, and usage examples, see the Adapters Overview.

Quickstart

Start MinIO and Redis with a single docker-compose command and run your first backtest in under 10 minutes.

Architecture Overview

Understand how the 16 adapters, MinIO bucket layout, and Redis minute-index work together to satisfy the backtest-kit write durability contract.

Adapters Overview

Full reference for every IPersist adapter — object key format, Redis index behaviour, upsert semantics, and cold-index fallback.

Build docs developers (and LLMs) love