Machine config
shipped 1.0.0The machine layer. Never committed, and there is one per machine rather than one per project.
version: 1
cloudron_host: my.example.com
defaults:
uploads: proxy
scrub: true
backup_before_push: true
snapshot_before_pull: true
snapshot_before_bricks_write: true
projects:
example: ~/Code/example/example.com
capabilities: # written by cwp, not by you
wp_allow_root:
my.example.com: false
defaults
Each key here is the default a project’s own setting starts from. pull.uploads
in cwp.yml overrides defaults.uploads; a flag overrides both.
They spell the same idea deliberately. cwp config get <key> --explain prints
the chain and marks the winner. Reach for it when a run does not do what the
file says.
The three *_before_* keys are the safety defaults, and switching one off is a
per-machine decision that applies to every project on it. --no-backup,
--no-snapshot and --yes are the per-run form.
projects
cwp init writes it and
cwp projects reads it. init only ever
adds, so a renamed, moved or deleted project leaves an entry pointing nowhere.
cwp projects reports that entry rather than hiding it, and names
cwp projects rm as the fix.
Removing an entry removes a line from this file and nothing else. No directory, no config, no database, no remote.
capabilities
cwp writes it and cwp reads it. It caches what a host turned out to need. The probe then runs once instead of on every run.
Today it holds one thing. wp_allow_root records, per host, whether remote
WP-CLI needs --allow-root: Cloudron’s wrapper drops privileges under a
non-interactive cloudron exec and does not need it, a plain ssh host may. The
probe is one wp --info. It runs as a read, so a dry run learns the same answer
a real run would. The result lands here.
Delete the block to force a re-probe. Deleting is the supported way to clear it. A host rebuilt with a different image can answer differently, and cwp has no way to notice on its own. Nothing else in the file is cwp’s to write, and nothing here is yours to set.