dokploy-multi-service

Dokploy Multi-Service Architecture

When to Use This Skill

• When creating templates with 2 or more services
• When designing service dependency chains
• When planning database + app + helper service stacks
• When user asks about "multi-container" or "service dependencies"

When NOT to Use This Skill

• For single-container applications
• For sidecar patterns (use dedicated sidecar documentation)

Prerequisites

• Understanding of service dependencies (what calls what)
• Knowledge of startup order requirements
• Understanding of internal vs external service access

---

Architecture Patterns

Pattern 1: App + Database (2-tier)

Structure:

┌─────────────┐     ┌─────────────┐
│     App     │────▶│  Database   │
│  (web UI)   │     │ (internal)  │
└─────────────┘     └─────────────┘
       │
       ▼
  dokploy-network

Characteristics:

• App connects to both networks (external + internal)
• Database connects only to internal network
• App depends on database with service_healthy

Example (Paaster + MongoDB):

services:
  paaster:
    image: wardpearce/paaster:3.1.7
    depends_on:
      mongodb:
        condition: service_healthy
    networks:
      - paaster-net      # Internal
      - dokploy-network  # External (Traefik)
    # ... traefik labels, health check

  mongodb:
    image: mongo:7
    networks:
      - paaster-net      # Internal ONLY
    # ... health check, no traefik labels

networks:
  paaster-net:
    driver: bridge
  dokploy-network:
    external: true

Pattern 2: App + Database + Cache (3-tier)

Structure:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│     App     │────▶│  Database   │     │    Cache    │
│  (web UI)   │     │ (internal)  │◀────│  (internal) │
└─────────────┘     └─────────────┘     └─────────────┘
       │                   │                   │
       └───────────────────┴───────────────────┘
                           │
                     internal network