Host control files & INI reference

BOA's configuration is a four-layer stack, narrowest-scope-wins. From the root operator's side the two load-bearing surfaces are the host .cnf files (/root/.barracuda.cnf host-wide, /root/.${USER}.octopus.cnf per instance) and a large set of empty boolean marker files whose existence toggles behaviour. Below those sit the per-platform and per-site INI files that a tenant can edit without root.

This topic is the complete operator reference for all of it:

• every marker
• every _VAR
• the relocation of the operator-toggle markers from /root to /etc/boa
• the precedence rules that decide who wins

Two structural facts to keep in front of you:

• Empty markers are booleans. A .<feature>.cnf file is on when it exists, off when it is missing — content is irrelevant. touch to enable, rm to disable. Each table below shows the exact path the live reader checks, which for the migrated set is /etc/boa/, not /root/.
• .cnf is bash, INI is parsed Drupal-side. .barracuda.cnf / .octopus.cnf are sourced as bash on barracuda/octopus upgrade passes (plus a few read by per-minute cron); the INI templates are read by the PHP global includes on a ~60 s opcache TTL. That difference in refresh timing is why tenants do quick adjustments in INI and host policy lives in .cnf. The INI layers exist on Drupal and Backdrop codebases only, and a Backdrop site's settings file runs the same include chain as a Drupal site's; Grav and Textpattern sites and platforms have none.

The pages below cover the marker system as a whole, the two host .cnf references, the tenant-editable INI layers and their precedence, the module support matrix, and the XTRAS install-mode tokens.

See the Reference appendix for the consolidated variable and command tables, and Discontinued features for control variables and markers dropped from the stack.