> ## Documentation Index
> Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL.
> Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other.
> Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking.
> Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify.

# Configuration locking

> Pause automatic node configuration propagation and inspect queued configuration changes.

Configuration Lock prevents automatic configuration changes from being applied to a node. Use it when a node should keep its current configuration until an operator intentionally unlocks it.

When Configuration Lock is enabled, the cloud controller can continue to generate newer configuration, but the node can queue those changes instead of applying them automatically.

## Where to configure it

Configure node-level locking from the node configuration overlay:

1. Open **Infrastructure > Fleet > Nodes**.
2. Select a node.
3. Select **Configure node**.
4. Open **General Settings > Administration**.
5. Toggle **Configuration Lock**.
6. Select **Save**.

The same Administration area also includes Edge Sync settings when available. Edge Sync is related to offline orchestration, but Configuration Lock is the specific control for pausing automatic configuration propagation.

## When to use Configuration Lock

Use Configuration Lock when:

* A node is in a sensitive production window.
* You need to prevent automatic configuration changes during maintenance.
* You are troubleshooting a configuration difference.
* You need to stage cloud-side changes before allowing the node to apply them.

Do not leave Configuration Lock enabled longer than needed. Queued changes can make the node differ from the desired configuration in the cloud controller.

## Node-level and project-level behavior

Configuration Lock can be enabled at the node level. Project policy can also affect nodes in the project. When project-level locking is enabled for a standard project, new or existing nodes in that project can inherit the locked behavior.

Use project-level locking carefully because it changes behavior for more than one node.

## Inspect configuration status

Use **Configuration Status** on the node detail page to inspect whether configuration is current.

1. Open the node detail page.
2. Select **Configuration Status**.
3. Review generated and fetched configuration timestamps.
4. Check whether the drawer reports a difference or error.
5. Select **Show Details** when you need to inspect the configuration content.

Configuration status is the best place to confirm whether a locked node has unapplied configuration changes.

## Unlock and apply changes

1. Open the node detail page.
2. Select **Configure node**.
3. Open **General Settings > Administration**.
4. Turn **Configuration Lock** off.
5. Select **Save**.
6. Open **Configuration Status** and monitor whether the node fetches and applies the latest configuration.

Some lifecycle events can still generate configuration changes. Use the configuration status drawer to verify what the node has fetched.

## Verify the result

After changing Configuration Lock:

* Confirm the toggle shows the expected state.
* Open **Configuration Status**.
* Confirm generated and fetched configuration timestamps make sense.
* Review any difference or error details.
* Check node health and Applications if the unlock applied pending changes.

## Next steps

* Review [Node status and health](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/node-status-and-health.md) if the node does not report the expected state.
* Use [Node details](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/node-details.md) to inspect Workloads, Adapters, and Storage after applying queued configuration.
* Use [Manage node lifecycle](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/manage-node-lifecycle.md) only if a lifecycle action is needed after configuration changes.