Containerized Auto Trading System

# Overview

A containerization and distributed systems project extending my production cryptocurrency trading platform. I'm applying Docker, Infrastructure as Code, and zero-trust security principles to transform a manual-deployment system into a scalable, multi-cloud architecture with central web management and one-command node deployment.

The Existing System (See original project)

• ✅ Already running in production
• ✅ Executes real trades across multiple user accounts
• ✅ Trading bots working, managed through Telegram
• ✅ Core functionality proven and stable

The Problem I'm Solving The system works great, but scaling it is painful:

• Deploying to new servers = manual setup every time
• ZMQ networking requires VPNs or direct TCP (doesn't work through NAT)
• No central management interface
• Monitoring means SSH-ing into each server
• Keys copied everywhere (security risk)

My DevOps Extension I'm modernizing the architecture with Docker and distributed systems patterns:

• Containerize everything (dashboard + separate node containers)
• One-command deployment anywhere
• Central web dashboard for management
• Zero-trust security architecture
• Multi-cloud capability

# Why I'm Building This

Refining My DevOps Practice I'm a developer with DevOps experience - servers, CI/CD pipelines, deployment automation. This project is about mastering containerization and Infrastructure as Code (IaC) by modernizing my production trading system.

What I Already Know

• Server management and configuration
• CI/CD pipeline setup and automation
• Deployment scripting and automation
• Production system operations

What I'm Mastering

• Container orchestration - Docker, multi-container systems
• Infrastructure as Code - Declarative configuration, reproducible environments
• Distributed systems patterns - Service communication, data sync strategies
• Zero-trust security - Modern credential management and isolation
• Multi-cloud architecture - Design for any cloud provider

The Gap I'm Closing I know how to deploy to servers. Now I'm learning to design systems that:

• Deploy anywhere with one command
• Scale horizontally without manual configuration
• Operate independently across cloud providers
• Survive network failures gracefully

This is real infrastructure work, I'm applying containerization to solve actual scaling problems in a live system.

# What It Does

The Architecture

Two Containers, Infinite Scale

Container 1: Dashboard (Central Management)

• MySQL database with encrypted user API keys
• Infisical KMS for master encryption key
• Trading bots (multiple instances, web-managed)
• React dashboard for management
• Signal broker (ZMQ → WebSocket bridge)
• Telegram bot for notifications

Container 2: Node (Trade Execution)

• Executes trades on Binance
• Manages user streams (real-time updates)
• Requests API keys temporarily when needed
• Maintains local cache for speed
• Syncs results periodically

Security-First Design

This is the part I'm most proud of. The system assumes compromise will happen - but limits the damage.

Zero Trust Credential Management Never trust, always verify - even inside your own system

• Dashboard stores encrypted API keys in MySQL
• Master encryption key lives in Infisical KMS (separate service)
• Nodes request keys temporarily when creating clients (60-second expiry)
• Raw keys wiped from memory immediately after use
• Only client objects stored in memory (never on disk)

What Nodes Store

• User metadata (user_id, username, telegram_id) - that's it
• Binance listen keys (session tokens, not credentials)
• Balance snapshots (for position calculations)
• Trade history (synced periodically with the main server)

What Nodes DON'T Store

• ❌ API keys (never on disk)
• ❌ API secrets (never on disk)

Why KMS on Same Server is Safe Key Management Service - think of it as a vault for your encryption keys

• Infisical runs in same Docker network (isolated from host)
• Has its own authentication (app token, not root access)
• Even if server compromised, attacker needs both DB access AND Infisical token
• All access attempts logged for audit trail

Final Defense Layer: Binance IP Whitelist

• Even if attacker gets everything
• Even if they decrypt all keys
• They can't trade (wrong IP)
• Would need user's Binance account + 2FA + email

# Technical Stack

Container Runtime

• Docker - Package apps with dependencies into containers
• Docker Compose - Orchestrate multiple containers locally
• Python 3.11

Dashboard

• FastAPI - Modern async Python web framework
• MySQL 8.0 - Relational database for encrypted keys and analytics
• ZMQ - Fast internal messaging between bots and broker
• Supervisord - Process manager (keep bots running, restart on crash)
• React 18 - Frontend UI framework
• TypeScript - Type-safe JavaScript
• Vite - Fast build tool for frontend
• Infisical KMS - Open-source secret management

Node

• Python 3.11, SQLite (lightweight local database)
• python-binance (exchange API wrapper)
• aiohttp (async HTTP client)
• websockets (real-time communication)

DevOps Tools

• GitHub Actions CI/CD - Automated testing and deployment pipeline
• Nginx - Reverse proxy and load balancer
• Multi-stage Docker builds - Smaller final images by separating build and runtime

# What I'm Learning

I have DevOps foundations. This project deepens my expertise with containerization and distributed systems design.

1. Container Orchestration

Moving from manual deployments to containerized systems

Applying Docker to real production code:

• Container design - Split monolithic apps into logical services
• Inter-container communication - Networks, ports, API boundaries
• Volume management - Persistent data across container restarts
• Multi-stage builds - Optimizing image sizes and layer caching
• Health checks - Self-healing containers with proper monitoring

2. Infrastructure as Code (IaC)

Declarative configuration over manual setup

Reproducible environments:

• Docker Compose - Define multi-container systems declaratively
• Configuration management - Environment-based configuration
• Reproducible builds - Same environment everywhere, every time
• Version-controlled infrastructure - Infrastructure changes tracked like code

3. Distributed Systems Design

Patterns for resilient multi-service architectures

The architecture patterns I'm implementing:

• Local cache + sync - Speed through locality, consistency through periodic sync
• Offline operation - Services work when central systems are down
• Event-driven communication - Pub/Sub for signals, REST for sync
• Fault tolerance - Graceful degradation when components fail

4. Zero-Trust Security

Modern credential management and isolation

Security architecture that assumes compromise:

• Credential isolation - Keys exist only where needed
• Temporary access - Time-limited key access (60-second expiry)
• KMS integration - Separate service for master encryption keys
• Defense in depth - Multiple security layers, final fallback to IP whitelist

5. Cloud-Native Architecture

Design for any cloud, not tied to one

Building portable infrastructure:

• Multi-cloud deployment - Dashboard on GCP, nodes on AWS, your choice
• Loose coupling - Services communicate through APIs, not direct dependencies
• Horizontal scaling - Add nodes without reconfiguring the system
• Provider independence - Design works on any cloud provider

# Project Status

This is a DevOps modernization of my existing production trading system.

Original System ✅

• Trading bots fully functional
• Multi-user operation working
• Telegram management operational
• See the original project here

DevOps Extension Planning

• Analyzed existing MT Trader v3 codebase
• Designed 2-container architecture (Dashboard + Node)
• Security architecture documented (zero-trust credential management)
• Implementation roadmap created

Currently Building

• Project setup and directory structure
• Dashboard backend (FastAPI) - central management API
• Dashboard frontend (React) - web UI
• Local database module for nodes (SQLite caching layer)
• Docker containerization

Next Steps

• Sync API endpoints (node ↔ dashboard communication)
• WebSocket signal broadcasting (real-time trade signals)
• KMS integration with Infisical (master encryption key storage)
• Multi-cloud deployment testing

# Why This Project Matters

This isn't just "containerized code." It's my entry into the DevOps world through a real project solving real problems.

Production-Grade Infrastructure

• Proper security boundaries between components
• Credential isolation (zero trust)
• Defense in depth (multiple security layers)
• Assumes compromise, limits damage

Modern DevOps Practices

• Container orchestration (Docker + Docker Compose)
• CI/CD pipelines (GitHub Actions)
• Multi-cloud deployment capability
• Centralized management dashboard

Real Security Experience

• Zero trust architecture implementation
• KMS integration (Infisical)
• Key rotation strategies
• Compromise containment design

My DevOps Portfolio Piece This project showcases:

• DevOps fundamentals → Containerization mastery - Taking existing infrastructure skills to the next level
• Real-world modernization - Applying containers and IaC to solve actual scaling problems
• Production architecture patterns - Distributed systems, zero-trust security, multi-cloud design
• Infrastructure evolution - Transforming manual deployments into one-command containerized systems