Skip to main content
Use converge when component-owned files differ from the dispositions and settings recorded in .libops/site.yaml, for example after pulling template changes or editing managed Compose configuration by hand. The command always builds the same typed plan used by component reconciliation and safety checks.

​
Reference

Compare the active project’s component-owned configuration with the durable desired state in .libops/site.yaml, show the complete change plan, and apply the approved changes needed to restore alignment. Unknown components, invalid desired state, and changes sitectl cannot classify block mutation. Destructive changes are identified in the plan. By default each component change requires confirmation; --yolo skips that safeguard. Pass --report to inspect the plan without changing files. The active plugin supplies the component contracts while sitectl uses the same planning and reconciliation path as component reconcile, validate, and verify. Examples: sitectl converge sitectl converge --report sitectl converge --component fcrepo sitectl converge --yolo

​
Workflow

​
Relationship to validate

validate, verify, and converge consume the same reconciliation plan. Validation fails when desired state is missing, a component is unknown, or component-owned configuration has drifted. verify also refuses to hide those configuration failures behind successful runtime checks.

​
Plugin flags

Core routes convergence through the active plugin’s component contract:

​
Safety behavior

The plan identifies changes that may restart services and destructive removals. Secret-bearing details are hidden. If sitectl cannot reproduce intent or classify an operation, it reports the unknown and does not mutate the project. Review the resulting Git diff before deployment and use normal version-control recovery if the proposed source changes are not appropriate.