Why credentials survive a reflash
You will understand how GoSD keeps a device's settings safe across a reflash, and why the identity key is different.
This page only applies when you deploy to an SD-card device.
An SD-card device runs on GoSD, the appliance framework atfs images are
built with. GoSD keeps its own copy of every setting you change, separate
from the boot partition. This copy lives under /data/.gosd/config/ on the
device’s own data storage. It is what lets a reflash restore your settings
instead of erasing them.
Reflashing a different image restores your settings
Any code change produces a different image, even a no-op rebuild. GoSD reads a different image as a deliberate reflash. On boot, it compares the new image’s shipped defaults against its kept copy of your settings. It then restores your values onto the new card automatically.
Reflashing the exact same image wipes them
A byte-identical image is read differently. GoSD assumes a shipped default that matches the card exactly means someone reverted a setting by hand. It leaves the card’s shipped defaults in place, and deletes its own kept copy of your settings.
Caution
Reflashing the exact same image file wipes the card’s saved settings. Build or download a new image first, even for a same-version reflash, if you want your settings to survive.
The identity key is not a setting
The libp2p identity key lives separately, in atfs’s own data directory, not in GoSD’s settings config store. A reflash never touches it, whichever image you use, matching or not. Only clearing the data directory entirely removes it.
A full storage wipe is exactly what happens during an ATFS-EMMC-UNHEALTHY rebuild. That is the one case where the identity key is lost along with everything else.