talosctl apply full replacement in Talos OS v1.6.0 limits repeatable development environments

Direct answer for v1.6.0

In Talos OS v1.6.0, talosctl apply pushes a full configuration state to the node. There is no documented --patch or --merge flag in v1.6.0, and talosctl generate provides scaffolding without diff or merge assistance. The reception behavior is a full replacement; the execution impact is selective based on what changed. There is no confirmed public guidance that a delta-only apply flag will be introduced, and future release plans are not verified in this context. Full-replace reception is uniform, but impact varies by section.

Confirmed facts

talosctl apply in v1.6.0 transmits the entire desired configuration file rather than YAML key deltas. The Talos API compares the incoming state to the running state and decides which components need updates. Repeatable applies are supported by maintaining a single source of truth and reapplying the complete file. Some changes are applied dynamically, others require service restarts or node reboots. No native --patch flag exists in v1.6.0, so external diffing is required before apply.

Likely explanation

The system is state-based. A full file is expected so the node can converge to the declared state. Because the API performs value comparison internally, reapplying an unchanged file is expected to be a no-op for most sections, but applying a file that contains defaults different from the running state can trigger restarts. This is a likely behavior pattern, not a verified guarantee for all sections.

Repeatable apply steps for this case

1. Keep a complete machine and cluster config in version control as the single source of truth.
2. Export the running config for comparison:

   talosctl get machineconfig -n <node-ip> > current_config.yaml

3. Diff locally before apply:

   diff current_config.yaml desired_config.yaml

4. Apply the full file only:

   talosctl apply-config -n <node-ip> -f desired_config.yaml

5. Monitor logs during apply:

   talosctl logs -n <node-ip> -f

6. Avoid partial files. Applying an incomplete file can overwrite settings with defaults and cause instability.

Uniformity across sections

Reception is uniform: the whole config is replaced. Impact is not uniform. Network and cluster settings often update dynamically or via service restart. Kernel arguments and boot settings typically require a node reboot. Disk and partitioning changes may require destructive actions. Behavior may vary slightly between control plane and worker schemas in v1.6.0.

Missing diagnostic detail: which configuration sections are edited most frequently in your workflow, e.g., machine.network, cluster.apiServer, machine.kernel. That changes the risk assessment for reboots and restart frequency.