Docker Deployment
Relevant source files
The following files were used as context for generating this wiki page:
Memory Context Browser (MCB) utilizes containerization to provide a consistent, high-performance environment for its MCP server operations. The deployment strategy focuses on supporting local development with services like Ollama for embeddings and Milvus for vector storage, while also providing a path for scalable production environments via Kubernetes.
The Docker deployment architecture is designed to manage MCB's multi-provider capabilities, ensuring that AI coding agents have reliable access to persistent memory and semantic search tools regardless of the underlying host environment.
Container Architecture and Environment
The MCB deployment consists of the core application container interacting with various infrastructure providers. In development and testing scenarios, Docker is used to orchestrate dependencies such as vector stores and local LLM runners.
Component Interaction Flow
The following diagram illustrates how the MCB container interacts with external providers and infrastructure components within a containerized environment.
Sources: README.md:14-22, k8s/README.md:15-20
Key Deployment Components
| Component | Purpose | Context |
|---|---|---|
| MCB Container | Main MCP server executing tools and handling requests. | Core Application |
| Ollama | Local embedding provider for natural language queries. | Local Provider |
| Milvus/Qdrant | Vector stores for semantic code search indices. | Persistence Layer |
| Redis | Distributed cache for performance optimization. | Scalability |
| PostgreSQL | Metadata storage for sessions and memories. | Persistence Layer |
Sources: README.md:14-22, k8s/README.md:15-20, k8s/README.md:55-70
Configuration and Orchestration
Deployment behavior is governed by environment variables and profile-specific YAML configurations. The project uses standard Docker patterns for environment injection and service management.
Environment-Based Configuration
MCB uses different profiles (Development, Test, Production) that determine which containerized services are utilized.
- Development: Frequently uses
Ollamafor embeddings andMilvusfor vector storage, typically bound to port3000. - Production: Often leverages cloud APIs (OpenAI, Gemini) or high-availability container clusters, typically bound to port
8080. - Testing: Uses lightweight containers like
FastEmbedandEdgeVecfor rapid CI/CD cycles.
Sources: AGENTS.md:230-245, README.md:46-60
Build and Lifecycle Management
The project provides a Makefile that abstracts Docker operations through the make dev command family.
make dev WHAT=docker-up # Starts containerized dependencies
make dev WHAT=docker-down # Stops and removes containers
make dev WHAT=docker-logs # Tails container logs
make dev WHAT=docker-test # Runs tests within a containerized environment
Sources: AGENTS.md:155-165
Orchestration with Kubernetes
For production-grade deployments, the project provides a comprehensive Kubernetes (K8s) suite. This setup handles horizontal auto-scaling and high availability beyond basic Docker Compose capabilities.
Deployment Sequence
The deploy.sh script automates the application of K8s manifests, ensuring a specific order of operations to maintain service integrity.
Sources: k8s/deploy.sh:10-75, k8s/README.md:44-53
Horizontal Pod Auto-scaling (HPA)
The deployment is configured to scale between 2 and 10 replicas based on resource utilization and custom metrics.
- CPU Threshold: 70% average utilization.
- Memory Threshold: 80% average utilization.
- Custom Metrics: Requests per second (100 req/pod) and active connections (50/pod).
Sources: k8s/README.md:85-95, k8s/kustomization.yaml:70-75
Resource Management and Health
The containerized environment includes strict resource limits and health checks to ensure stability.
Health Check Configuration
The application exposes endpoints for container orchestrators to monitor status:
- Liveness Probe:
/api/alive(checks every 10s). - Readiness Probe:
/api/alive(checks every 5s). - Startup Probe: Monitors initial boot with a timeout of 6 attempts.
Sources: k8s/README.md:105-110, tests/e2e/admin-functional.spec.ts:18-30
Resource Constraints
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 2000m
memory: 4Gi
Sources: k8s/README.md:97-103
Summary
MCB's Docker deployment provides a flexible foundation for running a high-performance MCP server. By leveraging containerized providers for embeddings and vector storage, the system ensures consistent behavior across developer machines and production clusters. The inclusion of Kubernetes manifests and automated deployment scripts facilitates advanced operational requirements such as auto-scaling, automated TLS, and comprehensive monitoring through Prometheus integration.