Skip to main content

Docker Compose

This page answers a practical question: when should a team use FlowLayer instead of Docker Compose for day-to-day work?

The short answer is that they solve different orchestration layers.

What this tool is good at​

Docker Compose is strong when you want container-native workflows:

  • reproducible environments based on images
  • explicit container networking and volumes
  • consistent local-to-CI behavior for containerized stacks
  • straightforward multi-container startup from one manifest

Where FlowLayer differs​

FlowLayer orchestrates local processes and runtime commands, not containers.

Key differences:

  • process topology from one runtime session
  • explicit startup ordering with service dependencies and readiness checks
  • live runtime control through the remote TUI (flowlayer-client-tui)
  • logs streamed as part of the FlowLayer session protocol

If your services are mostly source-based local processes (for example app servers, workers, and simulators), this model can reduce iteration friction.

When to choose FlowLayer​

Choose FlowLayer when you need:

  • multi-service local orchestration without wrapping everything in containers
  • ordered startup and targeted restarts across dependent services
  • remote TUI access to a shared runtime session for collaborative debugging
  • distributed development simulations on one controlled host

When not to choose FlowLayer​

Prefer Docker Compose when you need:

  • image-centric workflows and container runtime parity
  • container network and volume behavior as first-class concerns
  • environments that are already standardized around Compose files

Honest summary​

FlowLayer does not replace Docker Compose.

Compose remains the better fit for container orchestration workflows. FlowLayer is useful when your main need is process-level developer orchestration, runtime ordering, and remote session control.