Delete VPS Checklist: 10 Steps Before You Delete a Server (2026)

Before you delete a VPS, copy its data off and verify the copy, remove the DNS records and allowlists that point at its IP addresses, revoke the keys and tokens it held, and then delete the server rather than stop it, because a stopped server is still billed. This delete VPS checklist puts those jobs into ten steps, in the order that avoids the two costly mistakes: losing data you cannot get back, and leaving your hostname pointed at an IP address the provider will hand to someone else.

Commands are for Ubuntu 24.04 LTS, with Debian 12 differences noted, and come from the official documentation for rsync, MySQL, MariaDB, PostgreSQL, Docker and GitHub Actions. HourlyVPS rules, such as what happens to the disk and what you pay, are quoted from our Terms and billing rules.

Key takeaways

• Copy data off the server and verify it with checksums before anything else: at HourlyVPS a deleted disk cannot be recovered, and snapshots may be deleted with the server.
• Remove A and AAAA records, then wait out the TTL, before you delete: the IP returns to the pool, and a dangling record lets the next holder serve, and get certificates for, your hostname.
• SPF entries, firewall allowlists and webhooks trust an address rather than a server, so clean them up along with DNS.
• Revoke tokens, deploy keys, CI runners and VPN peers at the service that issued them; deleting the disk does not invalidate them.
• Stopping a server does not stop billing; deleting does. HourlyVPS bills by the hour, never more than the plan's monthly price in a billing period, so you can delete the moment the checklist is done.

The delete VPS checklist at a glance

#	Step	Why it matters	Done when
1	Inventory the server	You cannot save or unhook what you have not listed	inventory.txt lists IPs, open ports, services, timers, crontabs, containers
2	Dump the databases	Copying live database files can capture a half-written state	Each dump ends cleanly or lists its contents
3	Archive configs, app folders and keys	Configs are your rebuild recipe; app keys decrypt your data	files.tar.gz lists without errors
4	Copy everything off the server	Data left on the server is deleted with the disk	The export folder is on your own storage
5	Verify the copy	An unchecked backup is a hope, not a backup	sha256sum -c prints OK for every file
6	Decide on a snapshot	Whether a snapshot survives the delete depends on the provider	You know where your copy lives after the delete
7	Remove DNS records, wait out the TTL	The IP goes to someone else: subdomain takeover	dig returns no A or AAAA answer
8	Remove IP-based trust	SPF, allowlists and webhooks trust an address, not a server	Nothing outside the server names its old IP
9	Revoke keys, tokens, runners and VPN peers	Credentials stay valid after the machine is gone	Each issuer lists nothing for this server
10	Delete (do not stop), then verify	A stopped server is billed like a running one	The server is gone from the portal and charges have stopped

Run steps 1 to 5 in one SSH session plus one terminal on your own computer. In every command, replace alex with your user name, 203.0.113.10 with the server’s IPv4 address and app.example.com with your hostname.

Step 1: List what runs on the server and what points at it

A short inventory tells you what to save in steps 2 to 4 and what to unhook in steps 7 to 9. Save it in the export folder: it also documents the server for the next time you deploy the same setup.

mkdir -p ~/export
ip -brief address show scope global | tee ~/export/inventory.txt
sudo ss -tulpn | tee -a ~/export/inventory.txt
systemctl list-units --type=service --state=running | tee -a ~/export/inventory.txt
systemctl list-timers --all | tee -a ~/export/inventory.txt
crontab -l | tee -a ~/export/inventory.txt
sudo crontab -l | tee -a ~/export/inventory.txt

If Docker is installed, add the containers and named volumes (prefix sudo if your user is not in the docker group):

docker ps -a | tee -a ~/export/inventory.txt
docker volume ls | tee -a ~/export/inventory.txt

Read the output with steps 2 to 9 in mind:

• Addresses: note the IPv4 and the IPv6 address. You will search your DNS zone, SPF record and allowlists for both.
• Listening ports: a database port means a dump in step 2; port 443 usually means a hostname with a certificate, which means DNS work in step 7.
• Services and timers: each one you installed, such as a bot, a CI runner or a backup timer, either needs a clean shutdown or has to be re-created on the next server.
• Crontabs: scheduled jobs often push data to, or pull data from, another machine. Both ends need a look in step 8.

How do you back up a VPS before deleting it?

Back up in three layers: database dumps for live data, archives for configs, app folders and Docker volumes, and a checksum file that proves the copy arrived intact. Put everything in ~/export so that a single transfer takes it all.

Dump databases instead of copying their files

A database writes all the time, so copying its data directory while it runs can capture a half-written state. A dump is a consistent copy. Ubuntu 24.04 ships MySQL 8.0, and the MySQL 8.0 manual explains that --single-transaction dumps InnoDB tables as they were when the dump started, without blocking applications. Stored routines and events are left out unless you add --routines and --events; triggers are included by default.

sudo mysqldump --single-transaction --routines --events --all-databases > ~/export/mysql-all.sql
tail -n 1 ~/export/mysql-all.sql

A finished dump ends with the line -- Dump completed on followed by a date. On Debian 12 the default database server is MariaDB 10.11: mariadb-dump takes the same options and ends with the same line.

For PostgreSQL, which is version 16 on Ubuntu 24.04 and 15 on Debian 12 (the commands are the same), pg_dump exports one database at a time without blocking readers or writers. Roles and other cluster-wide objects need pg_dumpall --globals-only. The custom format (-Fc) is compressed and restores with pg_restore.

sudo -u postgres pg_dump -Fc appdb > ~/export/appdb.dump
sudo -u postgres pg_dumpall --globals-only > ~/export/pg-globals.sql
pg_restore --list ~/export/appdb.dump | head

pg_restore --list reads the archive’s table of contents without connecting to a database; if it prints a list, the file is readable. A “could not change directory” warning from sudo -u postgres is harmless.

Database inside a Docker Compose stack? Run the dump in its container and add -T. Docker’s reference notes that docker compose exec allocates a pseudo-TTY by default; -T turns it off, so the dump is piped straight into the file instead of through a terminal.

docker compose exec -T db pg_dump -U app -Fc app > ~/export/app.dump

Small bots often keep their state in SQLite. Stop the bot so nothing changes after the copy, then use the sqlite3 shell’s .backup command. Write the full target path, because ~ is not expanded inside the quotes.

sudo apt install sqlite3
sqlite3 /srv/bot/bot.db ".backup /home/alex/export/bot.db"

Archive configs, app folders and Docker volumes

Configs are the recipe for the next server. /etc holds system and service settings such as SSH, Caddy or nginx, the systemd units you wrote and WireGuard keys; your app folder holds code and .env files. tar runs with sudo so it can read root-only files, while your own shell writes the archive, so you can download it later. Replace /srv/myapp with your app folder. The exclude keeps the archive from trying to include itself; write it without a trailing slash, because GNU tar does not match /home/alex/export/ against the folder.

sudo tar --exclude=/home/alex/export -czf - /etc /home/alex /srv/myapp > ~/export/files.tar.gz
tar -tzf ~/export/files.tar.gz > /dev/null && echo "archive OK"

GNU tar prints Removing leading `/' from member names; that is normal. Then record the packages you installed by hand, so the next server is one apt install away:

apt-mark showmanual > ~/export/packages.txt

For Docker named volumes, Docker’s documentation backs up with a throwaway container that mounts the volume and a host folder, then runs tar. Compose prefixes volume names with the project name, so take the exact name from docker volume ls in your inventory. From the project folder, stop the stack first so files do not change mid-copy:

docker compose stop
docker run --rm -v myapp_data:/data:ro -v /home/alex/export:/backup ubuntu tar -czf /backup/myapp_data.tar.gz -C /data .

Copy the export off the server and verify it

On the server, write a checksum file for everything in the folder:

cd ~/export && sha256sum * > SHA256SUMS

On your own computer, pull the folder with rsync. -a keeps permissions and timestamps, -v lists each file, and -P shows progress and keeps partial files if the connection drops. The trailing slash on export/ copies the folder’s contents rather than the folder itself.

rsync -avP [email protected]:export/ ./vps-export/

No rsync on your machine? scp -r [email protected]:export ./vps-export does the same job, without resuming. Then check every file:

cd vps-export && sha256sum -c SHA256SUMS

Every line must end in OK. On macOS, run shasum -a 256 -c SHA256SUMS instead. The export now holds secrets such as .env files and private keys, so keep it on encrypted storage, not in a shared folder.

Optional: prove the export restores

A checksum proves the copy arrived intact, not that it restores. For data you cannot rebuild, rehearse the restore before you delete the original: deploy a throwaway hourly server with the same OS, copy vps-export to it with rsync, restore, look at the data, then delete the throwaway. On HourlyVPS, a Quartz Q1 runs at $0.01/hour, billed by the hour. For PostgreSQL, on the throwaway server:

sudo apt install postgresql
sudo -u postgres psql < ~/vps-export/pg-globals.sql
sudo -u postgres pg_restore -C -d postgres < ~/vps-export/appdb.dump
sudo -u postgres psql -d appdb -c '\dt'

The globals file reports that the postgres role already exists; PostgreSQL’s documentation calls that error harmless. -C creates appdb from the archive, and the last command lists its tables. The same idea works for any database: restore with its own client, then query a table you know.

Should you take a snapshot before deleting a VPS?

Only if you know the snapshot outlives the server. Providers differ. Our Terms of Service say HourlyVPS snapshots may be deleted when the server is deleted, so they are a rollback tool while the server exists, not a way to keep it. DigitalOcean’s documentation (last verified July 13, 2026) says the opposite for Droplets: snapshots and volumes are not destroyed by default and stay in your account as separate resources, and snapshot storage is charged by size each month.

Option	What it keeps	Survives deleting the server?	Use it when
Export off the server (steps 2 to 5)	Data, dumps, configs	Yes: it is on your storage	Always, for any server you are about to delete
Rebuild recipe in Git: Compose file, Caddyfile, cloud-init, setup notes	How to recreate the server	Yes	You will deploy the same setup again
Provider snapshot	The whole disk image	Depends on the provider: may be deleted at HourlyVPS; kept by default at DigitalOcean	Rolling back a risky change while the server still exists
Keep the server stopped	Everything	It is not deleted	Almost never: at HourlyVPS a stopped server is billed like a running one

For a temporary server, the export plus a rebuild recipe usually beats a disk image. An image freezes old packages and old keys; a recipe deploys a fresh, patched server that you harden in minutes with our VPS security checklist.

Remove DNS records before you delete: the subdomain takeover risk

When a server is deleted, its IP addresses go back to the provider’s pool and can be assigned to another customer; our Terms say so in section 10. Any DNS record that still points at the address now sends your visitors, and your hostname, to a stranger. The OWASP Subdomain Takeover Prevention Cheat Sheet lists A records that point to released IP addresses among the records at risk.

HTTPS does not protect you here. OWASP and Microsoft’s guidance on dangling DNS both note that whoever controls a hijacked subdomain can obtain a valid TLS certificate for it. From there, cookies scoped to your parent domain, OAuth redirects that trust the subdomain, and phishing on a name your users know all become possible.

OWASP’s safe order is: update or remove the DNS record, wait at least its TTL, then decommission the resource.

The common mistake is doing these steps in reverse: deleting the cloud resource first, which creates an immediate window for takeover that persists until someone notices the dangling record.

OWASP Cheat Sheet Series, Subdomain Takeover Prevention

1. In your DNS provider’s dashboard, search the zone for the server’s IPv4 address, its IPv6 address and its hostname. OWASP’s checklist covers CNAME, A, MX, NS and TXT records; also check AAAA records and any wildcard such as *.example.com that resolves to the server.
2. Note each record’s TTL, then delete the record or point it at a server you still control, such as your main site.
3. Wait at least the TTL; OWASP puts typical values at 300 to 3,600 seconds. A TTL of 3600 means resolvers may keep serving the old answer for up to an hour, so keep the server running until then. A one-day TTL (86400) keeps it running, and billed, for a day: 24 billed hours, $0.48 on a Quartz Q2. Use that time for steps 8 and 9.
4. Confirm from your own computer with the commands below.

dig +noall +answer A app.example.com
dig +noall +answer AAAA app.example.com

Before the change, each command prints the record with its TTL in the second column; afterwards, it prints nothing. Do not skip the AAAA check: Every server comes with one dedicated IPv4 address and IPv6, included in the plan price. An AAAA record left behind dangles exactly like an A record. If a record is proxied through a CDN, dig shows the CDN’s addresses, so check the record list in the CDN’s dashboard instead.

What else still trusts the old IP address?

DNS is the obvious pointer. Three more are easy to miss because they trust an address rather than a server, and whoever holds that address next inherits the trust: SPF records, allowlists, and anything that sends data to the server. A fourth, monitoring, only makes noise, but it belongs on the same list. Reputation travels the other way too: an IP address keeps its history when it changes hands, which is why our acceptable use policy asks every customer to keep the addresses they use off blocklists.

SPF records that let the IP send your mail

If the server sent email for your domain, your SPF record may list it as ip4:203.0.113.10 or with an ip6: entry. SPF’s ip4 and ip6 mechanisms match by address, so after reassignment, mail from that address can pass SPF for your domain. Look at the record, then remove the old address in your DNS dashboard:

dig +short TXT example.com

Firewall and database allowlists on other machines

Other servers, managed databases, admin panels and IP-restricted API keys may admit this address. Remove those rules. On another Ubuntu server that uses UFW, list the rules by number, then delete the rule that names the old address (rule 3 in this example):

sudo ufw status numbered
sudo ufw delete 3

A load-test box is a common case: the target’s firewall or WAF was told to let it through. See our k6 load-testing guide.

Webhooks, proxies and jobs that send data to the server

Webhooks deliver data to a URL: repository events, payment events, a Telegram bot’s incoming messages. If that URL uses the server’s hostname or raw IP, delete or repoint the webhook in the sending service. For a Telegram bot, call the Bot API’s deleteWebhook method. If the bot moves to a new host and uses python-telegram-bot, starting it in polling mode calls deleteWebhook for you, as our Telegram bot guide explains.

A reverse proxy or load balancer on another machine that forwards to this IP is the same risk in reverse: remove the upstream, or it will pass your users’ requests, cookies included, to the next holder of the address.

Check jobs on other machines that push to this server, too: backups, log shipping, metrics. Jobs over SSH fail loudly, because ssh refuses to connect to a host whose key has changed unless someone set StrictHostKeyChecking no. Plain HTTP and syslog have no such check and would deliver to whoever holds the address next.

Monitoring and alerts

Delete the external health check, the status-page component and any Prometheus scrape target for the server before you delete it. Otherwise you get paged for an outage you caused on purpose, and people learn to ignore that alert.

Revoke keys, tokens, CI runners and VPN peers

Credentials outlive machines. The deleted disk takes its copy of a key with it, but the key stays valid at the service that issued it, and your export now holds another copy. Revoke everything that existed only for this server.

Find the secrets on the box

sudo find / -xdev \( -name '.env' -o -name '.git-credentials' -o -path '*/.aws/credentials' -o -path '*/.docker/config.json' \) 2>/dev/null

Also check Environment= lines in the systemd units you wrote. For every token you find, such as model API keys, personal access tokens, cloud keys, registry logins or bot tokens, decide: revoke it, or move it to the next server on purpose. If the server may have been compromised, revoke them all; for a Telegram bot, Telegram’s docs say to generate a new token with BotFather’s /token command.

SSH keys the server used to reach other systems

If you generated a key pair on the server, for a Git deploy key or to reach other servers, its public half is still trusted wherever you added it. Print its fingerprint, then remove the matching key from the repository’s Deploy keys settings or your account’s SSH keys on GitHub, and from ~/.ssh/authorized_keys on other servers:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

GitHub lists keys by SHA256 fingerprint, which is what ssh-keygen prints by default, so you can match them exactly. Our Claude Code dev-box guide uses this kind of single-repo key.

GitHub Actions self-hosted runners

A runner stays registered after its server disappears. GitHub’s documentation says a self-hosted runner is removed automatically only after it has not connected for more than 14 days, or more than 1 day for an ephemeral runner. Remove it properly while the server still exists: in the repository, open Settings, then Actions, then Runners, select the runner and click Remove to get a time-limited removal token. Then run this in the runner folder on the server:

sudo ./svc.sh stop
sudo ./svc.sh uninstall
./config.sh remove --token TOKEN

Keep that order: on Linux, the runner’s own code refuses to unconfigure while its service is still installed and stops with “Uninstall service first”. Already deleted the server? Use Force remove this runner on the same page. Setup, the ephemeral pattern and the removal steps for a dedicated runner user are in our self-hosted runner guide.

WireGuard peers

For a trip VPN, delete the tunnel from the WireGuard app on each phone and laptop, so it does not keep trying to reach an address that now belongs to someone else. The next holder of that IP cannot complete a WireGuard handshake without the server’s private key, which they do not have, so this is tidiness rather than a leak. If the server was a peer of other servers, remove it there too, and delete its [Peer] section from /etc/wireguard/wg0.conf on each of them:

sudo wg set wg0 peer SERVER_PUBLIC_KEY remove

The full setup, with the per-device configs you will be deleting, is in our WireGuard VPN guide.

TLS certificates

Let’s Encrypt submits every certificate it issues to public Certificate Transparency logs, so the hostname of your test server is already public. That is one more reason to finish step 7. Retiring a server does not require revoking its certificate: OWASP’s checklist says to revoke it or let it expire. Revoke when the private key may have leaked, and remember that your export holds a copy, because /etc/letsencrypt is inside files.tar.gz. With Certbot:

sudo certbot revoke --cert-name app.example.com --reason keycompromise

If you revoke on a planned retirement, use --reason cessationofoperation instead. Certbot then asks whether to delete the certificate; answer yes, or certbot renew will try to renew it.

What happens to your data when you delete a VPS?

At HourlyVPS, deleting a server is immediate and cannot be undone: its virtual disk is deleted, and neither you nor we can recover it. The storage returns to the free pool, and a new server, yours or another customer’s, starts with an empty disk that cannot read what a previous server stored. Some records outlive the server, such as billing records and which account used which IP address and when; our Security page and Privacy Policy describe them.

Do you need to wipe the disk first? Overwriting files from inside the server is less reliable than it sounds. GNU’s shred documentation lists where overwriting fails: file systems that journal data or take snapshots, RAID, compressed file systems, and SSDs, whose wear leveling sends writes to other blocks. A virtual disk on NVMe storage adds layers you cannot see from inside the server, so you cannot confirm that an overwrite reached the original blocks.

If your own rules require sanitization, plan it when you deploy, not when you delete. Keep sensitive data on an encrypted volume from day one; destroying the key then makes the data unreadable, which NIST SP 800-88 Rev. 2 calls cryptographic erase. Our Security page gives the same advice: encrypt sensitive data inside the server, or overwrite it yourself, before you delete it.

At any provider, ask two questions before you delete: do backups or snapshots outlive the server, and for how long? DigitalOcean, for example, keeps the automated backups of a destroyed Droplet until they expire, four weeks after they were created.

Step 10: Delete the server, because stopping does not end billing

With steps 1 to 9 done, delete the server in the portal. Do not settle for stopping it: A stopped server is still billed, because its vCPU, memory, disk and IP addresses stay reserved for you; only deleting the server stops billing. HourlyVPS is not unusual here: of the 20 providers in our Hourly VPS Fine-Print Index, 12 bill a stopped server in full, 5 stop billing compute but keep billing storage, and 3 depend on how or what you stop (data checked October 2, 2026). The provider-by-provider detail is in which VPS providers bill stopped servers, and Vultr vs DigitalOcean vs Hetzner billing compares three large clouds rule by rule.

What you pay until the delete. Every server is billed by the hour: the plan’s hourly rate is deducted from the server’s prepaid balance for every hour it exists, powered on or off, until you delete it. Billing is by the hour: every hour a server exists is charged at the plan’s hourly rate. The price tapes and cost tables on this site count every started hour as a full hour, so they show the most a duration can cost; the cost calculator charges a partial hour to the nearest cent, as the bill does. Charges are deducted in whole cents: a full hour costs exactly the hourly rate, and a partial first or last hour is rounded to the nearest cent, never more than a full hour.

So rushing the delete saves very little; take the time to verify your export. An extra hour on a Quartz Q2 costs $0.02.

No cycle to wait out. HourlyVPS has no prepaid daily or monthly cycle, so there is no renewal to cancel and no paid period to wait for. A daily VPS is simply 24 hours of hourly billing, and a server you leave on stops costing more once its charges reach the plan’s monthly price in a billing period. Delete the server as soon as the checklist is done, and billing stops.

Each server’s hours are paid from its own prepaid balance, which starts with the initial credit you add when you order it. The Refund and Account Credit Policy sets out how account credit and server balances are handled, and how hourly VPS billing works walks through the hourly rate, the monthly cap and the initial credit with worked examples.

Letting the credit run out is not a shortcut. The server keeps using its balance every hour; when the balance runs low, the portal issues a top-up invoice, and when it reaches zero, the server is suspended for non-payment and deleted 7 days later unless you top up. That is a delete on someone else’s schedule, with no DNS or key cleanup, so run the checklist and delete the server yourself.

Verify after you delete

Check	How	Expected result
The server is gone	Server list in the portal	Not listed
Billing has stopped	Billing history in the portal	No hourly charges after the delete
DNS is clean	dig +noall +answer A and AAAA for each hostname	No answer
SPF is clean	dig +short TXT example.com	No ip4: or ip6: entry for the old addresses
The runner is gone	Repository Settings, Actions, Runners	Not listed
Webhooks are gone	Webhook settings of each sending service; Telegram’s getWebhookInfo	No URL on the old host; an empty url field for Telegram
Monitoring is quiet	Health-check and metrics dashboards	No check or target for the server
The export is intact	sha256sum -c SHA256SUMS on your storage	Every line ends in OK

What to save and revoke for common temporary servers

Most temporary servers follow a few patterns. Here is what each one needs before the delete:

Server	Save first	Unhook or revoke	Full guide
GitHub Actions runner	Usually nothing: job logs stay on GitHub	Remove the runner; revoke any token used only to register it	Self-hosted runner on a VPS
WireGuard trip VPN	Nothing: new keys cost nothing	Delete the tunnel on every device; remove the peer from other servers	WireGuard VPN on a VPS
Tailscale exit node	Nothing: a new server joins the tailnet as a new machine	Switch every device’s exit node to None, run sudo tailscale logout, remove the machine from the tailnet	Tailscale exit node on a VPS
Minecraft weekend server	The world folder, after stopping the server so every chunk is saved; server.properties, whitelist.json, ops.json	The DNS record your friends connect to	Minecraft server cost and backups
Palworld weekend server	The Pal/Saved folder, which holds the world and PalWorldSettings.ini, archived after stopping the server	The address your friends connect to	Palworld backup and restore
Valheim weekend server	The whole save folder (IronGate/Valheim: worlds and the admin, ban and permitted lists), archived after stopping the server	The address your friends connect to	Valheim backup and restore
Telegram or Discord bot	The database (often SQLite) and the .env file	Telegram deleteWebhook if it used a webhook; a new token if the box may be compromised	Telegram bot, Discord bot
n8n	The Postgres dump plus the .n8n folder with its encryption key	Webhook URLs registered in other services	Self-host n8n
AI agent or Claude Code box	Push every branch; copy notes and logs you need	Model API keys, deploy keys, Git tokens	Claude Code on a VPS, AI agents on a VPS
k6 load-test box	Result files and summaries	The allowlist entry on the target	Load testing with k6
Linux practice lab	Scripts and notes you wrote during the lab	The server’s line in your known_hosts file (ssh-keygen -R 203.0.113.10), so a reused address does not trigger a host-key warning	Learn Linux on a VPS

Next time, there is no billing mode to choose: the same hourly billing covers a job of a few hours, a daily VPS kept for a few days, and an always-on server, whose charges stop at the monthly price in each billing period. Compare plans on the pricing page or price your job’s hours in the VPS cost calculator.