When One Project Needs Many Terminals

A typical modern project can demand several long-running processes at once: a Docker stack in one terminal, a Rails server in another, webpack watchers in a third. It works, but it adds overhead — remembering every command, arranging windows, and keeping sessions organized across restarts. There's no single standard way to automate this, but the developer community has converged on a handful of useful approaches.

Terminal Multiplexers

The most frequently recommended solution is tmux, which creates multiple "fake" panes inside a single terminal session. These panes can be pre-configured to open and run different commands simultaneously at session startup. Example tmux configurations are easy to find, and the tmuxinator project wraps plain tmux with a more declarative, template-based configuration format.

Another terminal emulator worth a look is kitty, which some describe as "a grown-up tmux." Like tmux, kitty can be configured with layouts that launch specific commands at startup.

Native Terminal Splitting

Every major platform's terminal now has some built-in support for split panes, though the feature depth varies:

  • macOS: iTerm has long handled split panels well and can remember window arrangements, but it has no built-in option to trigger commands within a saved arrangement. The stock Terminal app offers basic tabs and splits that feel limited in comparison.
  • Linux: Terminator is the established tool for running several terminals in one window.
  • Windows: The default Windows Terminal supports panes natively.

Script Wrappers

For those working primarily in npm-land, concurrently and npm-run-all let you run multiple scripts from a single command. These are best suited to run-and-exit tasks, however, because output from all processes is interleaved in a single stream — not separated into individual panes — making them awkward for several run-forever watchers.

Scripting iTerm from the Outside

Because many macOS developers already live in iTerm, a natural strategy is to drive it programmatically. iTerm has long been scriptable via AppleScript, and although support is being phased out in favor of Python bindings, the legacy approach still works. The core pattern wraps the terminal in an AppleScript block:

The complete script, with comments, shows how to create new tabs and issue keystrokes to each. It's clunky — the final result creates tabs rather than the preferred split-screen layout — but it works and requires no additional tooling. The absence of a compiled app wrapper or direct Python support for this kind of layout control is a limitation worth noting.

Similarly, the Alfred launcher is popular in Mac circles for this exact workflow. Its automation capabilities extend to iTerm via custom workflows, giving users a keyboard-driven way to open a project's full suite of processes without remembering the underlying commands.