DROPLET_IP=<fill-this-in>
DROPLET_USER=<fill-this-in>

Set up Droplets from DigitalOcean on this VM by following the exe.dev recipe at https://exe-staging.dev/deploy/migrate-digitalocean-droplet.md from top to bottom.

The values at the top of this message are mine:
- DROPLET_IP: the droplet's public IPv4 address, from the **Droplets** page of DigitalOcean's control panel
- DROPLET_USER: the user you SSH in to the droplet as; `root`, or a user with passwordless sudo
Ask me for any that still say <fill-this-in> before you need them.

The recipe's example VM name is my-server. This VM's name is the output of `hostname`: use it wherever the recipe writes my-server. Skip the step that creates the VM; you are on it.

You are done when all of these are true. Check each one yourself:
- The VM reaches the droplet with a key of its own, and nothing on the droplet has changed or stopped.
- A survey of the droplet in `~/droplet/survey.txt`, and the plan of what moves in `~/droplet/plan`.
- The droplet's packages, users, files, databases, containers, and services on the VM, at the same paths and major versions, set to start on boot; its workers and cron jobs installed but off until the move.
- Its sites served on port 8000 behind `https://<vm>.exe.xyz/`, with `~/droplet/check` finding every page the same as on the droplet.
- A report in `~/droplet/report.md`: what moved, what changed for exe.dev, what couldn't move, and the owner's steps for the move.

Read the whole recipe, including the closed details, and do "Rehearse the
move by hand" in order, skipping VM creation; the walkthrough above it is
for the owner. You need the owner once, early: show them the command in
"Let the VM in" with this VM's name and the droplet's address and user,
and wait until `ssh droplet sudo -n true` works.
Only read from the droplet: never stop, restart, install, or change
anything there. Never run ~/droplet/move, change DNS, or run share
set-public: the move is the owner's call. Until then, keep the plan's
workers and cron off on this VM.
Keep passwords, keys, and .env values you come across out of your
replies and the report.
If the droplet runs something exe.dev can't (a mail server, inbound ports
other than HTTP and SSH), or something you'd have to rewrite rather than
move, don't work around it silently: put it in the report and ask.
Finish with the report's summary, https://<vm>.exe.xyz/, and the owner's
steps in "Make the move" with this VM's name and the droplet's domains.

Finish with the URLs I should open.