When to Split Stacks

Split stacks when one config hurts iteration speed more than it helps coordination.

Strong indicators

• most developers need only a subset of services daily
• startup time is consistently high for routine tasks
• optional integrations dominate CPU/RAM for little local value
• debugging signal-to-noise in logs is too low

Split strategy

1. Keep a core stack for high-frequency local work.
2. Move heavy or optional subsystems to dedicated configs.
3. Preserve shared naming conventions for cross-stack clarity.
4. Document which workflow uses which config.

What not to do

• do not split blindly by repository boundaries
• do not duplicate all services in every config
• do not hide hard dependencies to make a split look cleaner

Rule of thumb

If a service is required for most edits and tests, keep it in core. If it is episodic or role-specific, move it to an auxiliary stack.

See Giant Single Stack for the failure mode this avoids.