Prepare manager unlock before changing Swarm autolock

Bottom line: Make manager unlocking a planned maintenance dependency before enabling autolock. Keep authorized key retrieval and the restart sequence explicit so a normal daemon restart does not become an improvised credential-recovery exercise.

Source fact: documented behavior

The Lock your swarm to protect its encryption key documentation is the primary reference.

With Swarm autolock, Docker requires the generated unlock key after a manager restart; docker swarm unlock performs the documented unlock. When rotating the unlock key, Docker warns to retain the old key for a few minutes because a manager that stops before receiving the new key might still need it. The guide permits viewing the current key from a running Swarm with functional manager quorum when the key has not rotated since the unavailable node left; a later rotation changes that recovery situation.

What the source does not establish

This article reviews the documented unlock dependency and key transition, not a complete quorum or disaster-recovery design. It does not authorize forcing a manager to leave or promise recovery of a lost key. Keep protected key material out of ordinary maintenance evidence.

Applicability questions

• Who can retrieve the authorized unlock key during the maintenance window?
• Which managers will restart under the approved quorum plan?
• Did key rotation occur while any manager was unavailable?
• What observation confirms that the intended manager is usable again?

DSE recommendation: make key custody part of restart readiness

DSE recommends a restart checklist that identifies the authorized key custodian and an approved retrieval path before touching the daemon. Record only a controlled reference to the key, not its value. Confirm that the designated operator can use the retrieval process during the actual maintenance interval.

Review the permitted manager population and restart sequence with the Swarm owner. Keep the quorum design in its established procedure rather than inventing a safe number of simultaneous restarts from this article. Name the management observations required before the next approved step proceeds.

For a key rotation, preserve the old and new references with a restricted transition record. Identify any unavailable manager and review which key generation it might require. Follow the source’s short transition-retention warning within the organization’s approved key-handling process; do not discard the previous material solely because the rotation command returned.

Keep a lost-key or stale-manager problem outside the routine unlock path. Stop and use the separately reviewed recovery procedure when the expected key cannot be established. Avoid disabling autolock merely to make maintenance convenient without the responsible owner’s decision about the changed protection and recovery requirements.

Verification and evidence

Proposed verification, not performed: use a dedicated test Swarm under an approved manager-availability plan. Confirm protected key retrieval, perform the authorized daemon restart on the named manager and observe the actual unlock and return-to-management checkpoints. Keep key values outside captured output.

Use a separate bounded rotation exercise to examine current and prior key custody. A manager-unavailable case can be reviewed as a tabletop scenario instead of deliberately endangering a valuable cluster. Retain sanitized manager identities, key-generation references, timestamps and observed outcomes. Report unresolved retrieval or membership conditions explicitly rather than treating a successful command on one manager as proof of the whole recovery design.

Official references

• Lock your swarm to protect its encryption key — Docker Docs.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.