Mercury ABH Deployment
Overview
Process for deploying three concurrent instances of Mercury (A, B, H variants) on a single server for comparison testing in a semi-production environment.
Core Components
Docker Images
- Base image:
mercury-bot:latest- Built fromapps/mercury/Dockerfile.amd64 - Variant images: Tagged as
mercury-bot:{a|b|h}from base image
Database Infrastructure
- Three isolated PostgreSQL instances:
postgres-a(port 5432): Stores data for Mercury A variantpostgres-b(port 5433): Stores data for Mercury B variantpostgres-h(port 5434): Stores data for Mercury H variant
Application Components
Each variant (A, B, H) consists of:
- Bot service: Handles Telegram interactions (ports 3004/3005/3006)
- Worker service: Processes background tasks (ports 3001/3002/3003)
Supporting Services
- Redis (port 6397): Shared queue with database isolation via Redis DB indices
- Chroma (port 8000): Vector database for document storage
- OTEL Collector: Metrics collection
Deployment Process
1. Image Building
- Multi-stage Docker build using
apps/mercury/Dockerfile.amd64 - Fallback build process if primary build fails
- Image tagging for variant tracking (
a,b,h)
2. Database Provisioning
- Start isolated PostgreSQL containers
- Wait for database readiness with health checks
- Run migrations with variant-specific database connections:
DATABASE_URL="postgresql://postgres:postgres@localhost:{PORT}/mercury-{VARIANT}"
3. Service Deployment
- Start all services via Docker Compose
- Health check verification for each service
- Endpoint verification
Configuration Differences
Mercury A
- Bot port: 3004
- Worker port: 3001
- Redis DB: 1
- Tournament offset: 45 minutes
- Comparison method: "structured"
Mercury B
- Bot port: 3005
- Worker port: 3002
- Redis DB: 2
- Tournament offset: 75 minutes
- Comparison method: "structured"
Mercury H
- Bot port: 3006
- Worker port: 3003
- Redis DB: 0
- Tournament offset: -15 minutes
- Comparison method: "heuristic"
Limitations and Dependencies
Dependencies
- Docker and Docker Compose (v2 format)
- PostgreSQL with support for configuration parameters
- Redis with append-only mode
- Node.js for running migrations
Known Limitations
- All instances share a single Redis server (isolation via DB indices)
- Migration command requires DATABASE_URL override for each instance
- Shared system resources (CPU, memory) across all variants