~$ 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
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.
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.
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.