Trading Bot

Kubernetes Operator

The core of the project is a Kubernetes operator built with kube-rs. The operator watches for TradingBot custom resources and reconciles the cluster state to match — creating Deployments, ConfigMaps, and Services as needed, and cleaning them up when the resource is deleted via Kubernetes owner references and finalizers.

The binary runs in two modes selected at startup: --operator runs the controller loop in-cluster, while --api-server starts a standalone REST server exposing the Asset Registry. Both share the same compiled binary, which eliminates separate deployment artifacts and simplifies the release process.

Custom Resource Definitions

Two CRDs form the public API of the operator. TradingBot describes a single bot instance: strategy type and image, target exchange with API credentials sourced from a Kubernetes Secret, CPU/memory limits, and a full risk management block. AssetRegistry manages a catalogue of infrastructure assets — API endpoints, database connections, deployments, and config — with lifecycle tracking and dependency edges between entries.

Credentials are never stored in the operator or the database. The CRD spec holds only a Secret name and key path; the reconciler performs a targeted Secret lookup at runtime, keeping sensitive values out of any persisted resource.

apiVersion: trading.io/v1
kind: TradingBot
metadata:
  name: arb-bot-binance
spec:
  strategy:
    type: Arbitrage
    image: ghcr.io/example/arb-bot:latest
    parameters:
      minProfitThreshold: "0.005"
  exchange:
    name: Binance
    apiKeySecret: binance-creds
  riskManagement:
    maxPositionSize: "1000"
    dailyLossLimit: "200"
    stopLossPercentage: "2.5"

Asset Registry

The Asset Registry is a lightweight inventory system backed by SQLite via sqlx. Assets have a type (ApiEndpoint, DatabaseConnection, KubernetesDeployment, and others), a status lifecycle (Draft → Active/Inactive/Failed), tags, and UUID-based dependency references. The schema is created on first run — no separate migration step.

The REST API layer is built with Axum and documented automatically via utoipa, which generates an OpenAPI 3.0 spec directly from Rust type annotations. Full CRUD is exposed at /api/v1/assets with filtering by type, status, and tag.

Risk Management

Each TradingBot resource carries a declarative risk management block, making limits an explicit part of the resource definition rather than a runtime concern:

1. Max position size — caps the notional value of any single open position
2. Daily loss limit — halts the bot for the calendar day once reached
3. Stop-loss / take-profit — per-trade percentage thresholds
4. Max open positions — limits simultaneous exposure

Because these parameters live in the CRD spec, they are version-controlled, auditable, and can be updated with a plain kubectl apply — the operator picks up the change on the next reconcile cycle.

Build & Deploy

The operator ships as a multi-stage Docker image. The builder stage uses the official Rust image to compile a statically-linked binary; the final stage is a minimal distroless image running as a non-root user, keeping the attack surface small. RBAC manifests grant the operator only the specific Kubernetes permissions it actually needs — no cluster-admin shortcuts.

A Docker Compose file spins up a local Kind cluster alongside mock Binance and Coinbase exchange APIs and a Swagger UI instance, providing a self-contained development environment with no external dependencies.

Core Architecture Complete

The operator, REST API, and CRD definitions are fully implemented and compile cleanly. Remaining work is additive: trading strategy containers (the operator already manages their lifecycle), and fleshing out status-reporting — condition arrays and deployed-resource tracking are scaffolded and ready to be populated by the reconciler.