Oh, for upstream/base? If a Docker Hub image was set up with automated builds, it would automatically rebuild the image once its base was rebuilt. It looks like nginx was set up this way, but nginx-proxy was not. So you have to rebuild nginx-proxy manually.

  ~$ git clone https://github.com/jwilder/nginx-proxy
  ~$ cd nginx-proxy
  ~$ docker build -f Dockerfile.alpine -t my-own-tag-name/nginx-proxy:alpine .
  ~$ cd ..
  ~$ sed -i -e 's/image: jwilder\/nginx-proxy.*/image: my-own-tag-name\/nginx-proxy:alpine/' docker-compose.yaml

Alternately, you could fork the nginx-proxy repo, build it, push it to your own Docker Hub account, and add the Repository Links[1] back to nginx. Then you could use TravisCI to automatically pull in and rebuild changes from the parent nginx-proxy. This way you get automated builds when base is updated, and when nginx-proxy is updated.

[1] https://docs.docker.com/docker-hub/builds/#repository-links

Yes, it is entirely possible to do the right thing.

The trouble is 9 times out of 10, the only place you find it documented is in some random forum post where cargo-cult silliness gets critiqued, rather than by the folks publishing these how-tos.

These aren't even how-tos, they're clickblogs. If you'd like to contribute to actual HOWTOs for this kind of stuff, I'm building a wiki...

link to the wiki for a noob?

I try... it’s tough to keep up with everything, but I do try to merge nginx/security PRs promptly.

If you're hit by a bus tomorrow, at what point do folks know to migrate off your never-to-be-maintained-again image?

Don't get me wrong -- I'm not trying to discourage you from sharing configs and artifacts that work for you. They're valuable information to publish.

I just get terrified when I see folks regularly deploying images maintained by individuals rather than organizations.

Sure, that’s a valid concern. I think there are some other aspects of projects to consider than only the the org vs individual distinction though.

For example, I first wrote about nginx-proxy and docker-gen 4 years ago (http://jasonwilder.com/blog/2014/03/25/automated-nginx-rever...). Since then, both projects have gone through continued releases with bug fixes, updates and new features. Between the two projects, there are about 110 different contributors and I am no longer the top contributor on one of them.

The projects are MIT licensed and free to be forked or maintained independently if neeeded.

There’s a large community of users that write blogs, help with issues, and even create derivative works inspired or derived from the project.

Finally, I’d add that a lot of orgs behind projects are really just an individual that wants to make a useful closed source project open for others. The org or company name attached doesn’t necessarily mean a company is going to support it any better than a dedicated individual or community that cares about it.