SharapovLab Trader: Multi-Exchange Crypto Trading Platform
An algorithmic crypto trading platform running live across five exchanges at once: a React 19 web terminal, a Node.js bot-server, Python trading bots, a Kafka event bus and PostgreSQL underneath it all.
Founder / Full Stack Developer
Updated 2026-07-29 · v4
Overview
SharapovLab Trader is built around a React 19 web terminal, a Node.js/Express bot-server, and a fleet of Python trading bots trading live across five exchanges simultaneously: Bybit, MEXC, Gate.io, BingX and HTX. Apache Kafka and PostgreSQL sit underneath as the system of record, so no third-party SaaS dependency sits anywhere in the critical path.
Problem
Running automated strategies across multiple exchanges usually means duplicating execution logic per exchange SDK. There's no single place to watch positions, risk, fills and bot health across all of them at once, and when something breaks, there's often no durable event trail explaining what happened.
Solution
Everything routes through one bot-server instead. Python bots built on ccxt trade live, or in paper/Monte Carlo mode, risk events and fills stream through Kafka into PostgreSQL, and a React dashboard gives one operating view across every bot, exchange key and position at once. Prometheus and Grafana watch the whole stack.
Architecture
- React 19
- TypeScript
- Vite
- Node.js
- Express
- Apache Kafka
- PostgreSQL
- Python
- ccxt
- Docker
- Kubernetes
- Prometheus
- Grafana
- OpenAI API
- Bybit API
- MEXC API
- Gate.io API
- BingX API
- HTX API
The web terminal runs on React 19, TypeScript and Vite, covering bot management, exchange settings, live charts, liquidation tracking and AI trade analysis. The bot-server (Node.js/Express) handles its own JWT auth, with the access token kept in memory and refresh sitting in an httpOnly cookie, plus bot process orchestration, encrypted exchange-key storage, WebSocket streaming and a Prometheus /metrics endpoint.
Python trading bots (ccxt, NumPy) support live, paper and Monte Carlo execution modes, sharing a common risk-guard and position-sizing library so the logic doesn't drift between modes. Apache Kafka, running in KRaft mode, acts as the event bus, with dedicated consumers persisting risk events and fills into PostgreSQL, which functions as the single source of truth, backed by time-partitioned migrations for candles, orders, fills and risk events. An OpenAI (GPT-4o-mini) proxy powers AI-assisted trade and screenshot analysis.
Docker and Kubernetes manifests cover the bot-server, frontend, Kafka consumers, Prometheus and Grafana, and a Docker Compose profile handles local Postgres plus Kafka without needing a cluster. Order execution talks directly to the Bybit, MEXC, Gate.io, BingX and HTX APIs. Bot-server storage runs on a Kubernetes PersistentVolumeClaim instead of an ephemeral volume, and exchange keys are scoped per user account, so a pod redeploy or a second logged-in account can't reset a bot's config or accidentally trade on someone else's keys. When the bot-server runs in-cluster, strategies launch as native Kubernetes Jobs rather than plain child processes.
Features
- One unified web terminal across five exchanges instead of a separate tool per venue.
- A homegrown auth system (bcrypt plus JWT access/refresh tokens), with no third-party auth dependency in the mix.
- Hardened registration: hCaptcha verification, enforced password rules, per-IP rate limiting, and an editable display name shown right in the dashboard header.
- A Kafka-backed event pipeline for risk events and fills, decoupled from the request path entirely.
- Portfolio analytics covering Sharpe, Sortino, Max Drawdown and Value-at-Risk, with exact per-fill PnL computed from quantity and contract size and fed straight into the risk-guard.
- Per-user exchange-key isolation and persistent bot storage, so configs and credentials survive pod redeploys and stay scoped to whoever actually owns them.
- AI-assisted trade and chart-screenshot analysis through OpenAI.
- Prometheus metrics and Grafana dashboards, out of the box, no extra wiring required.
- Kubernetes deployment scripts for a full local or cloud rollout, with strategies running as native Kubernetes Jobs in-cluster.
Technologies
- React 19
- TypeScript
- Vite
- Node.js
- Express
- Apache Kafka
- PostgreSQL
- Python
- ccxt
- Docker
- Kubernetes
- Prometheus
- Grafana
- OpenAI API
- Bybit API
- MEXC API
- Gate.io API
- BingX API
- HTX API
Gallery
Screenshots are being prepared and will land here through the dashboard.
Videos
Roadmap
Multi-exchange bot server + React web terminal
Kafka event bus + PostgreSQL persistence (Supabase/Privy removed)
Kubernetes deployment + Prometheus/Grafana monitoring
Per-user exchange-key isolation, persistent bot storage, hardened registration (hCaptcha, rate limiting)
Expanded strategy coverage and cloud (AWS EKS/RDS/MSK) rollout
Challenges
Five exchanges means five different API shapes, five different rate limits, five different flavors of order semantics, and keeping execution logic consistent across all of them took real work. On top of that, the platform had to migrate off external SaaS auth and data providers onto self-hosted PostgreSQL and Kafka without any downtime along the way.
Lessons
A Kubernetes Jobs deploy test exposed two sharp edges at once. Replacing the bot-server pod reset a bot's paper/testnet config, because that config lived on an ephemeral volume instead of anything persistent. Worse, exchange keys weren't scoped per user yet, so the next start ran live against a real key belonging to a different account entirely. The position got caught and closed manually before it became a real problem, but it's a good reminder: infrastructure assumptions that "work locally," shared volumes, shared credentials, turn into actual financial risk the moment multiple accounts or pod restarts enter the picture.
Future
Finishing the AWS (EKS/RDS/MSK) production rollout, and expanding strategy and monitoring coverage across the connected exchanges.
GitHub
Private, proprietary-licensed repository. There's no public codebase.
Demo
No public demo. The platform trades on private accounts.
FAQ
Which exchanges does SharapovLab Trader support?
Bybit, MEXC, Gate.io, BingX and HTX, all through one bot-server and one web terminal.
What powers the trading bots?
Python bots built on ccxt, running live, in paper mode, or in Monte Carlo simulation, sharing a common risk-guard library.
How is data persisted?
PostgreSQL is the single source of truth. Kafka carries risk events and fills to dedicated consumers that write them into Postgres.
Is the code open source?
No, it's a private repository under a proprietary license.