NO, just no. watchtower is a bad tool to "force" on users.

[rdebath]

Do not demand "Watchtower" in your default setup.

1. Watchtower is a security issue, it requires /var/run/docker.sock and so it has full capability to run as root on the host. As such it is a special case that should be checked and okay'd specifically by the end user.
2. You do seem to start watchtower in it's "Flagged containers only" mode, but you have omitted to name the container you want it to monitor.
3. You also have not included any scope arguments so it will kill other instances of itself.

You can (and perhaps should) suggest Watchtower, but putting it in the quick-start seems a supremely bad idea.

I do realise your pain with this, there is no good way of triggering automatic upgrades of docker images as part of docker, but Watchtower is not an image that should be run by a new docker user without warning.

[Arkiver2]

Do you have an alternative?

[rdebath]

Of course not, anything that uses docker to update has to run on the host or use tricks like mapping docker.sock to pretend that it doesn't. Remember Docker is not an image updating tool it's an image freezing tool.

To this extent putting it in nested virtual machines (eg: docker inside vitualbox) as you're doing with your "basic usage" is okay (Not brilliant though, because you now have a third OS to update!).

But if want to do automatic updates inside docker you have to bypass docker, the standard option is to do standard automatic upgrades (apt-get, unattended-upgrades, ... etc) to bypass just the "freeze". Otherwise you bypass Docker's VM and run some code on the host.

I think, for here, it would enough to have the inclusion of options that make it very clear that something has to run on the host. Perhaps by making a host only script, eg like this, that does the upgrades of your VM with verbiage that makes it very clear that watchtower is doing the same thing.

Note: That Stackoverflow question has a lot of possible ways of doing updates including watchtower and ways of polling hub.docker.com from inside the docker image to check for newer versions (but you still have the "upgrade self" problem because automatic upgrades are antithetical to "the docker way").

[rdebath]

Another note on this; I came across https://github.com/nestybox/sysbox (now part of Docker Inc)

This fixes the problem of running docker inside docker.
A full version of docker can be run inside docker without opening up access of the host to the guest and without running a full VM with a complete guest OS on the host.