Migrate from DigitalOcean to Vultr — Same Simplicity, More US Locations

I had been a DigitalOcean customer since 2014. Ten years. I liked their documentation, their clean UI, and the general developer-friendly vibe. So when I decided to migrate three production Droplets to Vultr in February 2026, it was not because I hated DigitalOcean. It was because I needed a server in Atlanta and DigitalOcean does not have a datacenter there.

That sounds like a trivial reason, but it was not. Our primary users were in the southeastern US, and our Droplets in NYC3 added 30–40ms of latency to every request. Vultr has datacenters in Atlanta, Miami, Dallas, Chicago, and five other US cities. DigitalOcean has New York and San Francisco. For a US-focused application, that geographical gap is real and measurable. A user in Birmingham, Alabama hitting a server in Atlanta gets 8ms latency. The same user hitting NYC gets 42ms. Multiply that by every API call, every page load, every database query that touches the server, and you are looking at a noticeably faster experience.

The migration itself was surprisingly smooth. Both providers speak the same language: Linux, Nginx, PostgreSQL, SSH. The hardest part was not technical — it was convincing myself to leave a platform I had been comfortable with for a decade.

1. Why Switch: DigitalOcean vs Vultr in 2026

Let me be specific about what each provider does better, because this is not a "Vultr is better at everything" article. DigitalOcean is genuinely excellent at some things. The question is whether what Vultr does better matters more for your particular use case.

Where Vultr wins:

• US datacenter coverage: 9 US locations (New Jersey, Chicago, Dallas, Los Angeles, Seattle, Atlanta, Miami, Silicon Valley, Honolulu) vs DigitalOcean’s 2 (New York, San Francisco). If your users are outside the coasts, this matters enormously.
• Pricing: Vultr is 15–20% cheaper at most tiers. 1 vCPU / 1GB: $5/mo vs $6/mo. 2 vCPU / 4GB: $20/mo vs $24/mo. The gap widens with bandwidth — Vultr includes 2–5TB vs DO’s 1–4TB.
• DDoS protection: Included free on all Vultr plans. DigitalOcean has no DDoS protection.
• Custom ISO: Vultr supports uploading your own ISO images. DigitalOcean does not.
• OS options: Vultr offers FreeBSD, OpenBSD, and Windows in addition to Linux. DigitalOcean is Linux-only.

Where DigitalOcean wins:

• Documentation: The best in the industry. Their tutorials are comprehensive, well-maintained, and cover nearly every Linux administration task.
• App Platform: A PaaS layer for deploying directly from Git. Vultr has nothing equivalent.
• Managed Kubernetes: DOKS is mature and well-integrated. Vultr Kubernetes Engine (VKE) exists but is newer.
• $200 free trial credit (60 days): vs Vultr’s $100 credit for 14 days.
• Community: Larger ecosystem, more third-party integrations, more Stack Overflow answers for DigitalOcean-specific questions.

2. Side-by-Side Cost Comparison

Plan	DigitalOcean	Vultr	Savings
1 vCPU / 1GB / 25GB SSD	$6.00/mo (1TB BW)	$5.00/mo (2TB BW)	17% + 2x bandwidth
1 vCPU / 2GB / 50GB SSD	$12.00/mo (2TB BW)	$10.00/mo (3TB BW)	17% + 50% more BW
2 vCPU / 4GB / 80GB SSD	$24.00/mo (4TB BW)	$20.00/mo (4TB BW)	17%
4 vCPU / 8GB / 160GB SSD	$48.00/mo (5TB BW)	$40.00/mo (5TB BW)	17%
Object Storage (250GB)	$5.00/mo	$6.00/mo	DO cheaper by $1
Managed PostgreSQL (1vCPU/1GB)	$15.00/mo	$15.00/mo	Same
Automated Backups	20% of Droplet price	$1/mo flat	Vultr far cheaper

The compute pricing difference is consistent but not dramatic — you save $4–$8/month per instance. Where the math really changes is backups: on a $48/mo Droplet, DO charges $9.60/mo for backups. Vultr charges $1 flat. If you are running 5 instances, that is $48 vs $5 per month just for backups. Over a year that is a $516 difference on backups alone.

3. Performance Benchmarks

I ran benchmarks on comparable plans from both providers (2 vCPU / 4GB), tested at their closest US East locations. Data from our benchmark database:

Metric	DigitalOcean NYC3	Vultr NJ
CPU Score	4,000	4,100
Disk IOPS (read)	55,000	50,000
Disk IOPS (write)	42,000	40,000
Network Throughput	980 Mbps	950 Mbps
Latency	0.8ms	0.9ms

Performance is effectively identical. DigitalOcean has a slight edge in disk IOPS; Vultr has a slight edge in CPU. In real-world usage you will not notice the difference. The performance argument for switching is about geographic proximity, not raw benchmarks. A Vultr server in Atlanta will always be faster for southeastern US users than a DigitalOcean server in NYC.

4. Pre-Migration Checklist

5. Step 1: Provision Your Vultr Instance

# Install Vultr CLI:
# macOS:
brew install vultr/vultr-cli/vultr-cli

# Linux:
curl -sL https://github.com/vultr/vultr-cli/releases/latest/download/vultr-cli_linux_amd64.tar.gz | tar xz
sudo mv vultr-cli /usr/local/bin/

# Authenticate:
vultr-cli config set api-key YOUR_VULTR_API_KEY

# List US regions (find the closest to your users):
vultr-cli regions list | grep "North America"
# ID    City           Country  Continent
# atl   Atlanta        US       North America
# mia   Miami          US       North America
# ewr   New Jersey     US       North America
# dfw   Dallas         US       North America
# ord   Chicago        US       North America
# lax   Los Angeles    US       North America
# sea   Seattle        US       North America
# sjc   Silicon Valley US       North America
# hnl   Honolulu       US       North America

# List plans:
vultr-cli plans list | grep "vc2"

# Create instance (Ubuntu 22.04, 2vCPU/4GB, Atlanta):
vultr-cli instance create \
  --region atl \
  --plan vc2-2c-4gb \
  --os 1743 \
  --label "myapp-production" \
  --ssh-keys YOUR_SSH_KEY_ID

# Get the new instance details:
vultr-cli instance list

I chose Atlanta (atl) because that is where our users are. If you are migrating from DO NYC, Vultr’s New Jersey (ewr) location is the closest equivalent. Pick the region that minimizes latency to your audience — use our US datacenter guide if you are unsure.

6. Step 2: Configure the New Server

# SSH into new Vultr instance:
ssh root@NEW_VULTR_IP

# Update system:
apt update && apt upgrade -y

# To replicate your Droplet exactly, first export installed packages from DO:
# (Run on the Droplet):
# dpkg --get-selections | grep -v deinstall > /tmp/packages.txt
# scp /tmp/packages.txt root@NEW_VULTR_IP:/tmp/

# On Vultr, install your core stack (match your DO environment):
apt install -y nginx postgresql-16 redis-server \
  certbot python3-certbot-nginx \
  ufw fail2ban git curl wget htop

# If using Node.js:
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs

# If using Python:
apt install -y python3-pip python3-venv

# If using PHP:
apt install -y php8.3-fpm php8.3-cli php8.3-pgsql php8.3-mbstring php8.3-xml

# Configure UFW (replicate your DO Cloud Firewall rules):
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'SSH'
ufw allow 80/tcp comment 'HTTP'
ufw allow 443/tcp comment 'HTTPS'
ufw --force enable

# Set up fail2ban:
apt install -y fail2ban
systemctl enable --now fail2ban

# Create deploy user:
adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

For a thorough hardening checklist, see our VPS security guide. The critical items: disable root SSH login, disable password authentication, configure firewall, install fail2ban, enable automatic security updates.

7. Step 3: Migrate Application Files

# === Option A: Clone from Git (cleanest approach) ===
ssh deploy@NEW_VULTR_IP
git clone git@github.com:yourorg/yourapp.git /var/www/yourapp
cd /var/www/yourapp
npm ci --production   # or: pip install -r requirements.txt
                      # or: composer install --no-dev

# === Option B: rsync from Droplet (if not using Git) ===
# Run from the DO Droplet (or any machine with SSH access to both):
rsync -avzP \
  --exclude='.git' \
  --exclude='node_modules' \
  --exclude='__pycache__' \
  --exclude='.env' \
  /var/www/yourapp/ \
  deploy@NEW_VULTR_IP:/var/www/yourapp/

# Install dependencies on Vultr:
ssh deploy@NEW_VULTR_IP "cd /var/www/yourapp && npm ci --production"

# === Copy configuration files ===

# Nginx config:
scp /etc/nginx/sites-available/yourapp root@NEW_VULTR_IP:/etc/nginx/sites-available/
ssh root@NEW_VULTR_IP "ln -sf /etc/nginx/sites-available/yourapp /etc/nginx/sites-enabled/"
ssh root@NEW_VULTR_IP "nginx -t && systemctl reload nginx"

# Environment file (copy manually, review each value):
scp /var/www/yourapp/.env deploy@NEW_VULTR_IP:/var/www/yourapp/.env
# IMPORTANT: Update DATABASE_URL, REDIS_URL, S3 endpoints in the .env

# Systemd service files:
scp /etc/systemd/system/yourapp.service root@NEW_VULTR_IP:/etc/systemd/system/
ssh root@NEW_VULTR_IP "systemctl daemon-reload && systemctl enable yourapp"

# Cron jobs:
crontab -l > /tmp/do-crontab.txt
scp /tmp/do-crontab.txt root@NEW_VULTR_IP:/tmp/
ssh root@NEW_VULTR_IP "crontab /tmp/do-crontab.txt"

8. Step 4: Migrate Databases

You have two options here: migrate to self-hosted PostgreSQL on the Vultr VPS (saves $15/mo, better latency) or migrate to Vultr Managed Databases (same price as DO, but in your chosen region). I went with self-hosted because colocating the database and application on the same server eliminates network latency for queries entirely.

# === PostgreSQL: DO Managed DB → Self-Hosted on Vultr ===

# Step 1: Dump from DO Managed Database:
pg_dump \
  "postgresql://doadmin:YOUR_PASSWORD@db-postgresql-nyc3-12345-do-user.ondigitalocean.com:25060/myappdb?sslmode=require" \
  --no-owner --no-acl --format=custom --compress=9 \
  --file=/tmp/myappdb.dump

echo "Dump size: $(du -h /tmp/myappdb.dump | cut -f1)"

# Step 2: Transfer to Vultr:
scp /tmp/myappdb.dump deploy@NEW_VULTR_IP:/tmp/

# Step 3: Create database and user on Vultr:
ssh root@NEW_VULTR_IP << 'REMOTE_EOF'
sudo -u postgres psql << 'EOSQL'
CREATE USER appuser WITH PASSWORD 'your-strong-password-here';
CREATE DATABASE myappdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE myappdb TO appuser;
EOSQL
REMOTE_EOF

# Step 4: Restore the dump:
ssh root@NEW_VULTR_IP "pg_restore -U postgres -d myappdb --no-owner /tmp/myappdb.dump"

# Step 5: Fix table ownership and grants:
ssh root@NEW_VULTR_IP << 'REMOTE_EOF'
sudo -u postgres psql -d myappdb << 'EOSQL'
GRANT ALL ON ALL TABLES IN SCHEMA public TO appuser;
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO appuser;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO appuser;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON SEQUENCES TO appuser;
EOSQL
REMOTE_EOF

# Step 6: Verify row counts match:
echo "--- DO Database ---"
psql "postgresql://doadmin:PASS@do-host:25060/myappdb?sslmode=require" \
  -c "SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 10;"

echo "--- Vultr Database ---"
ssh root@NEW_VULTR_IP "sudo -u postgres psql -d myappdb \
  -c \"SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 10;\""

# === MySQL: DO Managed DB → Self-Hosted on Vultr ===

# Dump from DO:
mysqldump \
  -h mysql-db-nyc3-12345-do-user.ondigitalocean.com \
  -P 25060 -u doadmin -p \
  --ssl-mode=REQUIRED \
  --all-databases --single-transaction --routines --triggers \
  > /tmp/do-mysql-dump.sql

# Transfer and restore on Vultr:
scp /tmp/do-mysql-dump.sql deploy@NEW_VULTR_IP:/tmp/
ssh root@NEW_VULTR_IP "apt install -y mysql-server && mysql -u root < /tmp/do-mysql-dump.sql"

# === Redis: DO Managed Redis → Self-Hosted on Vultr ===

# Redis is typically used as a cache, so migration = fresh start.
# If you need to preserve data:

# On DO, export Redis data:
redis-cli -h redis-do-host -p 25061 --tls --no-auth-warning -a YOUR_PASSWORD \
  --rdb /tmp/do-redis-dump.rdb

# Transfer to Vultr:
scp /tmp/do-redis-dump.rdb deploy@NEW_VULTR_IP:/tmp/

# On Vultr, stop Redis, replace dump file, restart:
ssh root@NEW_VULTR_IP << 'EOF'
systemctl stop redis
cp /tmp/do-redis-dump.rdb /var/lib/redis/dump.rdb
chown redis:redis /var/lib/redis/dump.rdb
systemctl start redis
redis-cli DBSIZE
EOF

9. Step 5: Migrate DO Spaces to Vultr Object Storage

# Install rclone (the best tool for cross-provider object storage migration):
curl https://rclone.org/install.sh | bash

# Configure both providers:
cat >> ~/.config/rclone/rclone.conf << 'EOF'
[do-spaces]
type = s3
provider = DigitalOcean
access_key_id = YOUR_DO_SPACES_KEY
secret_access_key = YOUR_DO_SPACES_SECRET
endpoint = nyc3.digitaloceanspaces.com
acl = private

[vultr-obj]
type = s3
provider = Other
access_key_id = YOUR_VULTR_OBJ_KEY
secret_access_key = YOUR_VULTR_OBJ_SECRET
endpoint = ewr1.vultrobjects.com
acl = private
EOF

# Sync everything from DO Spaces to Vultr Object Storage:
rclone sync do-spaces:your-space-name vultr-obj:your-vultr-bucket \
  --progress --transfers=16 --fast-list --checksum

# Verify file counts and total size match:
echo "=== DO Spaces ==="
rclone size do-spaces:your-space-name
echo "=== Vultr Object Storage ==="
rclone size vultr-obj:your-vultr-bucket

# Update application code — change the S3 endpoint:
# Before: SPACES_ENDPOINT=https://nyc3.digitaloceanspaces.com
# After:  SPACES_ENDPOINT=https://ewr1.vultrobjects.com
# The rest of your S3 SDK code stays identical.

10. Step 6: SSL Certificate Setup

# Option A: Let's Encrypt (after DNS cutover)
# First, test with --dry-run:
certbot --nginx -d yourdomain.com -d www.yourdomain.com --dry-run

# If dry-run passes, get the real certificate:
certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Verify auto-renewal:
certbot renew --dry-run

# Option B: Test BEFORE DNS cutover using a temporary subdomain
# Point staging.yourdomain.com → NEW_VULTR_IP, then:
certbot --nginx -d staging.yourdomain.com
# Test your app at https://staging.yourdomain.com
# After verifying, proceed with the real DNS cutover.

# Option C: If using Cloudflare (proxy mode / orange cloud)
# SSL is handled at Cloudflare's edge. On the VPS:
# - Set SSL/TLS mode to "Full (Strict)" in Cloudflare
# - Use Cloudflare Origin CA certificate on the VPS
# - No certbot needed

11. Step 7: Test Everything

I run the new environment for at least 48 hours before any DNS changes. Here is the testing protocol that has never let me down:

# 1. Test application by IP (bypass DNS):
curl -sH "Host: yourdomain.com" http://NEW_VULTR_IP/ | head -20
curl -sH "Host: yourdomain.com" http://NEW_VULTR_IP/api/health

# 2. Database connectivity:
ssh deploy@NEW_VULTR_IP "psql -U appuser -d myappdb -c 'SELECT COUNT(*) FROM users;'"

# 3. Redis connectivity:
ssh deploy@NEW_VULTR_IP "redis-cli PING"
ssh deploy@NEW_VULTR_IP "redis-cli INFO memory | grep used_memory_human"

# 4. Compare response times side by side:
echo "DO response time:"
curl -o /dev/null -s -w "%{time_total}s\n" https://yourdomain.com/api/health
echo "Vultr response time:"
curl -o /dev/null -s -w "%{time_total}s\n" -H "Host: yourdomain.com" http://NEW_VULTR_IP/api/health

# 5. Load test the new server:
# Install hey: go install github.com/rakyll/hey@latest
hey -n 10000 -c 50 -host "yourdomain.com" http://NEW_VULTR_IP/api/health

# 6. Run your application's test suite:
ssh deploy@NEW_VULTR_IP "cd /var/www/yourapp && DATABASE_URL='postgresql://appuser:pass@localhost/myappdb' npm test"

# 7. Test object storage (if migrated):
curl -I https://ewr1.vultrobjects.com/your-bucket/test-image.jpg

# 8. Test all cron jobs manually:
ssh deploy@NEW_VULTR_IP "crontab -l"
# Trigger each job and verify output

12. Step 8: DNS Cutover

# === If using DigitalOcean DNS ===

# First, export all DNS records for safekeeping:
doctl compute domain records list yourdomain.com --format Type,Name,Data,TTL,Priority --no-header

# Option 1: Move DNS to Cloudflare (recommended):
# - Add domain to Cloudflare
# - Recreate all DNS records in Cloudflare
# - Update domain registrar nameservers to Cloudflare's
# - Set A record to NEW_VULTR_IP

# Option 2: Move DNS to Vultr:
vultr-cli dns domain create yourdomain.com
vultr-cli dns record create yourdomain.com --type A --name "" --data NEW_VULTR_IP --ttl 300
vultr-cli dns record create yourdomain.com --type A --name "www" --data NEW_VULTR_IP --ttl 300
# Add MX, TXT, CNAME records as needed

# === If using Cloudflare or other external DNS ===

# Simply update the A record to the new Vultr IP:
# Via Cloudflare API:
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records/RECORD_ID" \
  -H "Authorization: Bearer YOUR_CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"content":"NEW_VULTR_IP","ttl":300}'

# === For write-heavy apps: final database sync ===

# 1. Enable maintenance mode on the DO Droplet
ssh root@DO_IP "touch /var/www/yourapp/maintenance.flag"

# 2. Final database dump (captures any writes since last sync):
pg_dump "postgresql://doadmin:PASS@do-host:25060/myappdb?sslmode=require" \
  --no-owner --no-acl --format=custom --file=/tmp/final.dump

# 3. Restore on Vultr:
scp /tmp/final.dump deploy@NEW_VULTR_IP:/tmp/
ssh root@NEW_VULTR_IP "pg_restore -U postgres -d myappdb --clean --no-owner /tmp/final.dump"

# 4. Flip DNS (already done above or do it now)

# 5. Start the application on Vultr:
ssh root@NEW_VULTR_IP "systemctl start yourapp"

# === Verify cutover ===

# Wait 5-10 minutes, then:
dig yourdomain.com +short
# → Should show NEW_VULTR_IP

curl -I https://yourdomain.com
# → HTTP/2 200

# Monitor Vultr access log for incoming traffic:
ssh root@NEW_VULTR_IP "tail -f /var/log/nginx/access.log"

# Verify DO Droplet is getting NO new requests:
ssh root@DO_IP "tail -3 /var/log/nginx/access.log"

13. Rollback Plan

14. Post-Migration Cleanup

# After 7-14 days of confirmed stability on Vultr:

# 1. Final safety snapshot of DO Droplet:
doctl compute droplet-action snapshot YOUR_DROPLET_ID \
  --snapshot-name "final-before-delete-$(date +%Y%m%d)"

# Wait for snapshot to complete:
doctl compute image list --public=false

# 2. Destroy the Droplet:
doctl compute droplet delete YOUR_DROPLET_ID --force

# 3. Delete DO Managed Database (if migrated off):
doctl databases delete YOUR_DB_ID --force

# 4. Cancel DO Spaces (after verifying all data is on Vultr):
# Delete via DigitalOcean web dashboard

# 5. Release DO reserved IPs, delete load balancers:
doctl compute reserved-ip delete YOUR_RESERVED_IP
doctl compute load-balancer delete YOUR_LB_ID --force

# 6. Remove DO DNS domain (if migrated):
doctl compute domain delete yourdomain.com --force

# 7. Enable Vultr automated backups ($1/mo):
vultr-cli instance update YOUR_VULTR_INSTANCE_ID --backups enabled

# 8. Set up monitoring on the new Vultr instance:
# (Prometheus + Grafana, or Vultr's monitoring if sufficient)

# 9. Verify your DO billing page shows $0 upcoming charges.

My entire migration — three Droplets, one managed database, one Spaces bucket — took 10 days from first Vultr instance to final DO cleanup. The active work was maybe 8 hours spread across those 10 days. The rest was monitoring and waiting for DNS. Average API response time for our southeastern US users dropped from 85ms to 48ms. Monthly cost went from $87 to $65. The savings are not life-changing, but the latency improvement was worth the effort on its own.

Related reading: migrating from AWS to VPS, Docker app migration between providers, our full Vultr review, and the DigitalOcean review for a detailed comparison.

FAQ

Is Vultr really cheaper than DigitalOcean for the same specs?

At every comparable tier, Vultr is 15–20% cheaper: $5/mo vs $6/mo for 1GB, $20/mo vs $24/mo for 4GB. Vultr also includes more bandwidth (2–5TB vs 1–4TB). The biggest savings come from backups: Vultr charges $1/mo flat regardless of instance size, while DO charges 20% of the Droplet price. On a $48 Droplet, that is $1 vs $9.60 for the same backup feature. Across multiple instances, the savings add up quickly.

Can I transfer a DigitalOcean snapshot directly to Vultr?

No, there is no direct snapshot transfer between providers. The migration path is: export your data from DigitalOcean using rsync or scp, provision a fresh Vultr instance with the same OS, and restore data on the new server. You could theoretically create a raw disk image on DO and upload it to Vultr as a custom ISO, but a fresh install with data restore is cleaner and avoids carrying over any cruft from the old server.

Does Vultr have managed databases like DigitalOcean?

Yes. Vultr Managed Databases supports PostgreSQL, MySQL, Redis, and Kafka. Pricing starts at $15/mo for a single-node PostgreSQL instance, identical to DigitalOcean’s. Both offer automatic backups, point-in-time recovery, read replicas, and connection pooling. If you use DO Managed Databases today, you can migrate to Vultr Managed Databases with minimal workflow changes.

What about DigitalOcean Spaces — does Vultr have equivalent object storage?

Yes. Vultr Object Storage is S3-compatible, same as DO Spaces. Vultr charges $6/mo for 250GB storage + 1TB transfer. DigitalOcean Spaces is $5/mo for 250GB + 1TB — DO is $1 cheaper here. Both use the S3 API, so migration is straightforward: rclone sync between providers, then update your endpoint URL and access keys in application code. The same boto3 or aws-sdk calls work on both platforms.

How long does the actual migration take?

A single Droplet with under 50GB of data takes 2–4 hours of active work, spread over 1–2 days for DNS propagation and monitoring. Multiple Droplets with managed databases and Spaces: 1–3 days. The data transfer bottleneck is network speed between providers, typically 50–100MB/s over SSH. A 50GB database dump transfers in 10–15 minutes. The rest of the time is setup, testing, and watching logs.

Will my application have downtime during migration?

With proper planning, downtime is under 5 minutes — limited to the final database sync window for write-heavy apps. The strategy: run both servers in parallel with synced data, lower DNS TTL to 300 seconds 24 hours ahead, do a final database sync during low traffic, flip DNS, monitor. For read-only or read-heavy applications, the migration can be truly zero-downtime since both servers can serve correct data simultaneously during DNS propagation.

Does Vultr have a CLI equivalent to DigitalOcean’s doctl?

Yes. Vultr has vultr-cli covering instance management, DNS, snapshots, backups, load balancers, object storage, and Kubernetes. The command syntax differs but capabilities are comparable. Vultr also provides a full REST API and an official Terraform provider (terraform-provider-vultr). If you use Terraform with the DigitalOcean provider, switching to Vultr’s provider is straightforward — resource concepts like instances, firewalls, DNS records, and load balancers map directly.