v2.0.2

🔧 Container updates are now faithful and safe

This release fixes how containers are recreated when you install an update from Home Assistant. Previously a recreated container could come back noticeably different from the original — or, in the worst case, not come back at all.

Networks are preserved (#191)

Recreated containers only kept the network from HostConfig.NetworkMode; every other network attachment was silently dropped, along with static IPs and aliases. Compose stacks with an internal project network plus a shared proxy network lost service discovery after every update (e.g. paperless-ngx no longer resolving its Redis broker).

Now all networks are reattached before the container starts, including ipv4_address/ipv6_address from IPAMConfig, network aliases and links. Thanks to @Azure340 for the detailed analysis.

Volumes and bind mounts are preserved

The mount configuration was rebuilt from the runtime mount list instead of being reused, which:

• detached named volumes from their data (the container came up with a fresh, empty anonymous volume),
• could fail with duplicate mount point for containers created with long-syntax compose mounts,
• dropped read-only flags.

HostConfig.Binds and HostConfig.Mounts are now passed through exactly as the container was created with.

Failed updates roll back

The old container used to be removed before the new one was created, so any failure during creation left you with no container. The old container is now renamed aside; if creating or starting the new one fails, the old one is renamed back and restarted. Updating a container that is already stopped no longer aborts, and failed updates no longer leave the container stuck in "updating".

📦 Dependencies

All dependencies updated to their latest versions, including better-sqlite3 13 and TypeScript 6. Fixed npm audit advisories (#666, thanks @Wheemer).

Full Changelog: v2.0.1...v2.0.2