Clone a droplet
Create an isolated copy with explicit disk consistency, credentials, and network identity.
Cloning creates a new droplet from a source configuration and selected disk recovery points. The clone receives a new resource ID, network interfaces, addresses, and execution ownership.
Choose the source state
Open Droplet → Clone and select a stopped source, ready snapshot group, or completed backup. A running source requires a supported snapshot consistency mode. Memory and live network sessions are not copied.
The clone preview lists the configuration revision and recovery point for each disk. Selecting the current configuration with an older backup can combine new settings with old data. Check application compatibility before accepting that combination.
Review identity before the first boot
Choose a new name and network. Public addresses, existing interface MAC addresses, and load-balancer membership are not copied. The default clone action places the guest on an isolated network with external routing disabled.
The disk copy can still contain application credentials, guest host keys, database cluster identities, and scheduled jobs. Infra cannot infer which files establish an application's identity. Prepare the clone with the application's supported reset procedure before connecting it to production services.
A clone from a prepared reusable image uses its initialization support to assign new guest identity. A byte-for-byte volume copy does not imply the same preparation.
Copy and placement
Select the target region, image compatibility, storage policy, and size. A same-region snapshot clone creates new volume resources. A cross-region clone requires a permitted completed backup or image copy in the destination.
Quota is reserved for the new droplet and volumes. Source reservations remain unchanged. Shared backing blocks can reduce immediate physical consumption, but the clone's logical storage allocation still counts against quota.
Validate an isolated copy
Start the clone without production traffic. Verify boot, filesystem state, application version, data consistency, and outbound integrations. Replace SSH host keys and application credentials where required by the clone's purpose.
For a standby database, perform the database's replica enrollment or recovery procedure. Two guests cloned from the same database disk must not both advertise themselves as the existing primary.
Failed or canceled cloning
A failed clone leaves the source unchanged. The operation lists partial volumes and image copies retained for cleanup or retry. Canceling after a volume copy finishes can retain that new volume even if the guest was never created.
Inspect the result before repeating the request. Use an idempotency key for API creation so a lost response does not create another clone. Use disaster recovery when the source can no longer be read.
Filesystem identifiers
A disk clone preserves filesystem and partition identifiers unless the guest preparation procedure changes them. Mounting the source disk and its clone in one recovery guest can therefore produce ambiguous UUID-based discovery.
Identify both attachments by their stable device serials before mounting. Change filesystem identifiers only through the filesystem's supported procedure and update the clone's mount and boot configuration accordingly. A new Infra volume ID does not imply a new guest filesystem UUID.