project dead? no commits in 2+ years. alternatives?

[utdrmac]

Is your feature request related to a problem? Please describe.

is this project dead? most recent commit was 2+ years ago. what are the alternatives?

Describe the solution you'd like

Solution: keep project alive

Describe alternatives you've considered

Unknown alternatives

Additional context

If the project is dead, please properly archive it so the community knows not to expect any new features/changes.

[bwitt]

I am considering https://github.com/getwud/wud as an alternative.

[o]

Wud seems cool AFAIK but you have to define the image version patterns for each image you're using, otherwise it recommends you random latest image in the registry. Watchtower works seamlessly and doesn't require much of a config. But I am also looking for the alternatives.

[utdrmac]

I tried WUD. It was too complicated. The terminology also doesn't make sense to me. Everything is a "trigger", including notifications. It also does not handle compose files with multiple containers very well. They really need to separate concerns.

I've switched to https://github.com/crazy-max/diun because all I really want is something to notify me when new images are available.

[thebigbone]

I think a maintained fork would be better because it's most likely widely used and no updates since 2 years has definitely halted at least the security patches from go and other dependencies it uses.

[JourneyOver]

Looking at the forks this one here https://github.com/beatkind/watchtower seems to be the most up to date and seems like he has plans on trying to keep things up to date as best as he can.

[MrExplode]

One alternative, idealistic solution could be updating your compose files with Renovate. However this requires a working IaC setup, opposed to Watchtower which works directly on the docker daemon.

The very clear advantage is Renovate's very customizable approach on updates, with breakage and adoption metric and others, compared to the simple version bumping Watchtower provides.
The downside is, as I said the IaC approach, which requires additional config for deployment.

[nicholas-fedor]

The Containrrr/Watchtower repository is definitely no longer under active development.
I opted to just fork and start updating things, but there's still plenty of work left, such as separating the notifications functionality away from Containrrr/Shoutrrr.

https://github.com/nicholas-fedor/watchtower

[brutaldev]

If anyone is looking for a simple non-container-based alternative, I've just open sourced ContainerUpdater: https://github.com/brutaldev/ContainerUpdater

[NeurekaSoftware]

If anyone is looking for a simple non-container-based alternative, I've just open sourced ContainerUpdater: https://github.com/brutaldev/ContainerUpdater

Your readme says that alternatives that use docker add unnecessary complexity. Can you elaborate on that?

[brutaldev]

@NeurekaSoftware
Simply that it's not a container and just a console/terminal app.
Just take a look at the Watchtower documentation, it can get pretty complicated to setup the container in the correct way to perform the updates especially if you use a lot of different compose groups and networks and various authentication mechanisms

The reasons I ended up building ContainerUpdater over other container-based solutions is:

• Basic setup for beginners is painful having to mount the right config and the correct sock depending on your OS and architecture.
• Using credential helpers requires special setup and isn't automatic.
• They often just don't work well in Windows.
• They tend to lose labels and grouping when recreating containers.
• Couldn't get them working using Podman.
• It's difficult to interact with the container compared to a regular console.
• I wanted to double click something to just get the job done...

I do list these things under the same "Alternatives" section.

[NeurekaSoftware]

@NeurekaSoftware Simply that it's not a container and just a console/terminal app. Just take a look at the Watchtower documentation, it can get pretty complicated to setup the container in the correct way to perform the updates especially if you use a lot of different compose groups and networks and various authentication mechanisms

The reasons I ended up building ContainerUpdater over other container-based solutions is:

• Basic setup for beginners is painful having to mount the right config and the correct sock depending on your OS and architecture.
• Using credential helpers requires special setup and isn't automatic.
• They often just don't work well in Windows.
• They tend to lose labels and grouping when recreating containers.
• Couldn't get them working using Podman.
• It's difficult to interact with the container compared to a regular console.
• I wanted to double click something to just get the job done...

I do list these things under the same "Alternatives" section.

I see, that's an interesting take. I can't speak for issues with Podman, but I've never had issues with labels and grouping when recreating containers. In fact, the compose file to setup watchtower is extremely simple. Just a few lines and your containers will stay up to date unless you need to pin versions. I've also had it working fine in Windows, but fwiw Docker Desktop is an entirely different beast with a huge set of problems. I really think having beginners copy a simple compose file is the easiest way to get started.

Do you plan to have your tool include a scheduler and run as a system process? I think keeping containers up to date is also important, and something beginners will forget to do (assuming this is aimed at beginners)- despite the potential risks with pinning latest.

[MrExplode]

Who exactly are you targeting with your solution? Anyone taking the effort to automate image updates (IMO) are

• not struggling with watchtower setup
• most definetly not running docker on windows
• do not have a problem with executing docker exec -it <container> /bin/sh

I've been running watchtower for years now in multiple environments, never experienced any of the mentioned problems.