GAIA

Appearance

Several conductors per repository ​

You'll learn how one checkout runs a conductor per GAIA project, how to name and select the configs, and why they cannot interfere with each other.

One repository can serve several products — a Drupal multisite is the sharpest case, where each site deserves its own project, tickets, board and conductor. GAIA supports that with N sibling engine configs in one .gaia/ directory, each bound to its own project:.

Naming ​

The default is the file named exactly conductor.config.js. Variants are <variant>.conductor.config.js:

.gaia/
  conductor.config.js        # gaia conductor start                     → the default
  shop.conductor.config.js   # gaia --conductor shop conductor start
  intra.conductor.config.js  # GAIA_CONDUCTOR=intra gaia conductor start

A file is a conductor config if and only if it is exactly conductor.config.js or ends with .conductor.config.js — an unrelated vite.config.js and the near-miss myconductor.config.js are both ignored.

Selecting one ​

Selection is per invocation, by the file's stem, and the flag goes before the subcommand:

sh
gaia --conductor shop conductor start
gaia --conductor shop conductor status
GAIA_CONDUCTOR=intra gaia conductor poll

The flag wins over the environment variable. With no selector: if conductor.config.js exists it is the default; else a single lone config is used; else the command errors and names the stems it found. --conductor conductor selects the default explicitly.

Why they never collide ​

Each config carries its own required machine_id, composed from the machine context and its own project: — so each is a distinct conductor on the control plane, with its own claims and its own workspace. gaia conductor ls lists all of them. A single-config repository resolves the same file and the same machine_id it always did; only adding a second config changes anything.

If a site also needs a different control plane, that is the one case for a project-local connection override — see Connection config.

Next ​