This document describes the Docker containerization strategy for the Sim platform, including multi-stage build configurations, Docker Compose orchestration, and resource requirements. The platform is designed to run as a set of distributed services, separating the web application, real-time collaboration, and background processing.
The Sim platform uses a multi-container architecture orchestrated via Docker Compose. The architecture separates the frontend/API layer, real-time collaboration layer, background workers, database, and one-shot migration tasks.
The following diagram maps high-level system components to their respective Docker services and internal code entities.
Sources: docker-compose.prod.yml1-134 docker/app.Dockerfile1-145 apps/sim/package.json21-22
All Dockerfiles use multi-stage builds to optimize image size and build caching. The application image (docker/app.Dockerfile) uses a four-stage process: base, deps, builder, and runner.
Key Implementation Details:
oven/bun:1.3.11-slim foundation, installing Node.js 22, Python 3, and ffmpeg to support multimedia processing blocks docker/app.Dockerfile4-12--linker=hoisted flag is used during bun install to ensure a flat node_modules structure, which is required for Docker multi-stage builds and avoids symlink resolution issues docker/app.Dockerfile29-33isolated-vm native module is rebuilt for the Node.js runtime (v22) to ensure stability for sandboxed code execution in Custom Tools docker/app.Dockerfile34standalone mode when DOCKER_BUILD=1 is set, significantly reducing the final image size apps/sim/next.config.ts77 docker/app.Dockerfile73requirements.txt docker/app.Dockerfile124-132Sources: docker/app.Dockerfile1-145 apps/sim/next.config.ts75-77 docker/realtime.Dockerfile1-84
docker-compose.prod.yml)Uses pre-built images from the GitHub Container Registry (ghcr.io). It enforces strict health checks to ensure the database is ready before migrations run, and migrations finish before the application services start.
| Service | Image | Role | Health Check / Dependency |
|---|---|---|---|
simstudio | ghcr.io/simstudioai/simstudio:latest | Next.js Web App | Depends on db, migrations, realtime docker-compose.prod.yml29-35 |
sim-worker | ghcr.io/simstudioai/simstudio:latest | BullMQ Worker | Command: bun apps/sim/worker/index.ts docker-compose.prod.yml43-45 |
realtime | ghcr.io/simstudioai/realtime:latest | Socket.io Server | Port 3002, depends on db docker-compose.prod.yml80-98 |
migrations | ghcr.io/simstudioai/migrations:latest | Drizzle Migrator | Command: bun run db:migrate docker-compose.prod.yml107-115 |
db | pgvector/pgvector:pg17 | Vector Database | pg_isready check docker-compose.prod.yml118-133 |
docker-compose.local.yml)Builds images locally from source using the respective Dockerfiles in the docker/ directory. It mirrors the production structure but sets NODE_ENV=development and uses local build contexts docker-compose.local.yml1-132
Sources: docker-compose.prod.yml1-137 docker-compose.local.yml1-132
The platform requires significant memory for LLM orchestration, vector operations, and sandboxed execution.
| Service | Memory Limit | CPU Limit | Purpose |
|---|---|---|---|
| simstudio | 8GB | 2000m | Web UI and API requests helm/sim/values.yaml31-33 |
| sim-worker | 4GB | 1000m | Background workflow execution docker-compose.prod.yml50 |
| realtime | 1GB | 500m | Collaborative editing and state sync docker-compose.prod.yml88 |
Technical Note: The 8GB limit for simstudio is critical because the Next.js standalone server and its internal caches require substantial overhead, especially when handling large file uploads or complex workflow validations docker-compose.prod.yml10
Sources: docker-compose.prod.yml7-10 helm/sim/values.yaml29-36
The GitHub Actions workflows automate the validation and preparation of Docker-ready artifacts.
Implementation Details:
test-build.yml workflow ensures the application can be built in a standalone configuration, mirroring the Docker builder stage .github/workflows/test-build.yml128-140migrations check ensures that the Drizzle schema and generated migrations are in sync by running drizzle-kit generate and checking for git diffs .github/workflows/test-build.yml115-126Sources: .github/workflows/test-build.yml1-146 apps/sim/package.json19-20
Containers are configured with security best practices to minimize the attack surface:
runner stage in app.Dockerfile creates a nextjs user (UID 1001) and group, ensuring the process does not run as root docker/app.Dockerfile99-101DATABASE_URL and NEXT_PUBLIC_APP_URL are provided during the builder stage to allow build-time code evaluation without requiring a live database connection docker/app.Dockerfile79-85sim-worker container allows fine-grained control over job concurrency per queue type (e.g., WORKER_CONCURRENCY_WORKFLOW=50) via environment variables docker-compose.prod.yml59-65Sources: docker/app.Dockerfile90-145 docker-compose.prod.yml51-65
Refresh this wiki