Problem
When migrating a deployrr setup to a new server with a different hostname or LAN IP, the restore process transfers files successfully but doesn't account for the changed values. This leaves .env files and Traefik file providers referencing the old hostname/IP, causing the Docker stack to come up empty or broken with no obvious error.
Real example from the community: a user migrated from one machine to another, changed the hostname (e.g. server2025 → server2026), and found their stack had nothing listed after restore. The fix was manually updating the hostname in .env — but this is easy to miss and hard to diagnose.
Proposed Solution
During the restore flow, prompt the user for:
- New hostname (pre-filled with the backed-up hostname, editable)
- New server LAN IP (pre-filled with the backed-up IP, editable)
After restore and before bringing up the stack, automatically update all relevant files with the new values:
.env files- Traefik file providers
- Any other config files that reference the hostname or LAN IP
This could be offered as a step in the restore wizard whenever the detected hostname/IP differs from the backup, or always as an optional override.
Why This Matters
Hostname and IP changes during migration are extremely common — nearly every migration involves a new machine. Without this, users hit a confusing failure mode (stack comes up empty) with no clear indication of what went wrong.
References
Discord thread: https://discord.com/channels/974306760171073556/1489647293199028315
Problem
When migrating a deployrr setup to a new server with a different hostname or LAN IP, the restore process transfers files successfully but doesn't account for the changed values. This leaves
.envfiles and Traefik file providers referencing the old hostname/IP, causing the Docker stack to come up empty or broken with no obvious error.Real example from the community: a user migrated from one machine to another, changed the hostname (e.g.
server2025→server2026), and found their stack had nothing listed after restore. The fix was manually updating the hostname in.env— but this is easy to miss and hard to diagnose.Proposed Solution
During the restore flow, prompt the user for:
After restore and before bringing up the stack, automatically update all relevant files with the new values:
.envfilesThis could be offered as a step in the restore wizard whenever the detected hostname/IP differs from the backup, or always as an optional override.
Why This Matters
Hostname and IP changes during migration are extremely common — nearly every migration involves a new machine. Without this, users hit a confusing failure mode (stack comes up empty) with no clear indication of what went wrong.
References
Discord thread: https://discord.com/channels/974306760171073556/1489647293199028315