How to Decommission Home Assistant Without Leaving Unprotected Data

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Decommission Home Assistant only after the replacement or archive is verified, every credential and remote route is revoked, and each disk, backup target, radio, and removable medium has an explicit disposition.

A Home Assistant host may contain far more than configuration.yaml: registries, database history, location data, secrets, API tokens, certificates, camera references, backup keys, add-on data, logs, and credentials for other services. Inventory those trust paths before shutdown, preserve only the protected recovery copies you intend to keep, then sanitize storage using a method appropriate to the media and its future owner.

Inventory Data and Trust Before Powering Down

List the active configuration directory, database, backups, add-on data, media, logs, external database, network shares, USB radios, cloud integrations, VPN or tunnel, DNS name, certificates, users, long-lived tokens, webhook URLs, and SSH keys. Record where each item lives and who can access it.

Map external systems that trust Home Assistant as well as credentials Home Assistant uses to reach them. A server can be offline while a leaked token, retained backup, shared SSH key, or public DNS route remains valid. Mark every item as migrate, archive, revoke, sanitize, or physically retain.

Use the ZimaSpace comparison of direct exposure and VPN access to inventory the remote routes, certificates, DNS records, and trust relationships that must be removed during retirement.

Verify the Replacement or Protected Archive

If Home Assistant is moving, run the new instance while the old controller is powered off or isolated, then test users, automations, radios, dashboards, history, notifications, remote access, and external dependencies. If the service is ending, restore the retained archive into an isolated test environment.

Confirm the archive is encrypted, the key is stored separately, and at least one copy sits outside the retired host. Record the backup date, source version, contents, checksum, retention owner, and planned destruction date so preserved data does not become permanent forgotten exposure.

Do not continue to wiping until the test proves the intended recovery outcome. If the replacement misses critical state or the archive cannot be decrypted, return to inventory and make a fresh verified copy before altering the source.

Revoke Credentials and Remove Network Exposure

Disable old Home Assistant users and long-lived tokens, rotate shared secrets, revoke cloud or integration authorizations, replace webhook URLs where possible, remove SSH keys, and change credentials that were stored on the host. Revoke from the external service side so a forgotten local copy cannot authenticate.

Remove port forwards, reverse-proxy routes, tunnels, VPN peers, public DNS records, certificates, monitoring checks, and automation callbacks aimed at the old host. Then attempt access from both LAN and remote paths; a timeout alone is not enough if DNS or credentials remain active elsewhere.

Keep a dated revocation record. If a shared credential cannot be isolated to the retired host, rotate it for every consumer and retest those consumers. Stop if credential changes break the replacement, because that reveals an undocumented shared trust path that must be separated.

Sanitize Every Data-Bearing Device and Verify the Result

Identify internal SSDs or HDDs, boot media, USB drives, radio storage, NAS copies, hypervisor snapshots, and cloud backups. Choose sanitization by media type and disposal plan; deleting files or reformatting a filesystem does not prove that sensitive blocks are unrecoverable.

For supported SSDs, cryptographic erase removes or replaces the encryption key rather than repeatedly overwriting flash, while vendor secure-erase tools may expose other media-specific methods. The important evidence is media-appropriate SSD sanitization, not a generic deletion command.

After sanitization, boot or mount the device in an isolated environment and confirm the expected empty or factory state, then record the method and result. Physically retain or destroy media when sanitization cannot be verified. The process ends only when the replacement works, retained archives are protected, trust is revoked, and no untracked copy remains.

Support & Tips

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.