Rebuild a Raspberry Pi VPN Appliance Without Copying Its Key

Booting once from an image does not make a Pi a rebuildable appliance. What you need is a small set of inputs you can reapply: a maintained base, a declared configuration, the application's persistent data, and a device identity that belongs to that board alone. Miss the last one and every replacement becomes a clone of a credential.

The steps below are an order of work rather than a tool recommendation. Any configuration system that can express them will do.

List the four kinds of input first

The base image and its packages define the operating system, the architecture and where updates come from, and an image builder only helps if the tool it names is still maintained for your release. The declared configuration is the part a human reviews: network roles, service settings and the lifecycle actions each service needs. Persistent application data is whatever the service cannot regenerate, and its location and backup method belong to that application rather than to the image. Device identities and secrets are the fourth input, and they are the one people forget when they clone a working card.

Write the four lists before rebuilding anything. A list with a blank row is a decision you have not made yet.

Keep secrets out of the repository and say where they live

A repository is a good home for reviewed templates and non-secret configuration, and a poor home for VPN private keys, reusable administrator credentials and diagnostic archives. If a secret has to exist on the device, record where it comes from, who can read it and how it is rotated. A key that lives only on one SD card is a single point of failure, while a key copied to every board is a fleet-wide credential with no owner. Neither is a recovery plan.

The test is simple: if the repository leaked tomorrow, what would an attacker gain? Templates and topology notes are survivable. A working identity is not.

Let automation own what it can rerun

Ansible's model keeps an inventory of managed nodes apart from plays, tasks, roles and handlers that fire when a task reports a change. Use that structure to give each service one configuration owner instead of replaying a shell history. Prefer operations that are safe to run twice, and decide deliberately how a changed file reaches the running process. A task that ensures a service is started does not necessarily make it reload a configuration you just rewrote.

Separate the stages of administration as well. Bootstrap connectivity, routine configuration and VPN-dependent management are three different windows, and the third can remove your own access if the rebuild resets the network underneath it. Keep an independent path in.

Restore data and identity on purpose

Container volumes persist independently of the container lifecycle, while the writable layer inside a container does not, which is why recreating a container from its image does not recreate the state the application was using, as the volume documentation describes. Record the volumes, bind mounts and external services the appliance depends on, and use the application's own backup and restore process. A container that starts without an error is not evidence that its database and its files agree.

For identity, decide whether you are recovering the same device or enrolling a replacement, because those are different operations with different cleanup.

Reconcile the old peer's access before activating an identity elsewhere, and only then test the rebuilt appliance in an isolated or recovery environment. Check the required data, the correct identity, an update path with an owner and the intended network policy.

A bootable image is one input among four, and it is the easiest one to reproduce.