The answer▚
If you self-host an AI assistant whose credentials live in a local vault (for example a OneCLI deployment), moving it to a new server is safe when you treat it as a trial rather than a cutover, and keep the old server running until the new one passes a real test.
- 01Inventory first. List the services, persistent data, environment settings, and connected accounts before you copy anything, so reconnecting becomes a checklist if a restore fails.
- 02Back up the source before you change it. For a default Docker-based deployment the persistent Docker volume is likely part of the backup, but verify your actual install rather than assuming a path.
- 03Find out how the encryption key is supplied. It may be set through an environment variable, or generated and stored with the application data. The restored data and its matching key must stay together, or encrypted credentials cannot be read.
- 04Copy only the real persistent state. Do not depend on a full virtual-machine image when moving between hosts that use different image formats.
- 05Restore onto the new server and confirm the vault can list existing connections and that at least one connector actually works before you rely on it.
- 06Use narrowly scoped, temporary migration credentials where you can, and revoke them once the move is confirmed.
If the vault will not decrypt or validate cleanly, stop. Use a fresh deployment with manual reconnection rather than forcing an undocumented recovery path, and do not discard the old server until the new one is proven.
Host-to-host vault restoration may not have an officially supported procedure, so follow the current OneCLI documentation and test in a reversible window.