Is .lerd.yaml config file meant to be committed to source control?

[chikondikamwendo]

I assumed that it is meant to be committed because it declares some important info i don't want to setup every single time. But then every time i start or stop a service or worker, it gets rewritten, for which I sometimes tend to have a commit for only that change that has no significance at all.

Is it possible to use that as a default config when first linking or until its persisted manually and then for the rest of the time use a temporary file outside of the repo?

[kgeminicdev]

Yes, .lerd.yaml is meant to be committed (project-setup docs). The churn you're seeing is by design: every start/stop command (queue:start, horizon:start, schedule:start, worker start…) updates the workers list in .lerd.yaml so a fresh clone or reinstall restores them (queue-workers docs).

What you're describing already exists as .lerd.local.yaml (configuration docs): an untracked file next to .lerd.yaml whose keys win over the committed ones. lerd link adds it to .git/info/exclude automatically, so it never shows up in git status.

So keep the team defaults in .lerd.yaml, and put your own working set in the local file:

# .lerd.local.yaml
workers:
  - queue
  - schedule

From reading the save path (restoreLocalOverrides in internal/config/project_local.go): once the local file owns workers, a save keeps the committed workers value in .lerd.yaml, so start/stop no longer produces a diff (lerd prints a warning that the key is overridden locally). Workers still start and stop; only isolate, isolate:node and link refuse to change a locally owned key.

One trade-off: lerd doesn't write to .lerd.local.yaml for workers, so your starts/stops aren't remembered there. After a reinstall, lerd start restores the list in your local file. Edit it by hand when you want to change your own default.