> First, please stop putting your binaries in /app, please, pretty-please? We have /usr/local/bin/ for that. I'm not sure about this idea. Usr local is where y

> First, please stop putting your binaries in /app, please, pretty-please? We have /usr/local/bin/ for that. I'm not sure about this idea. Usr local is where you'd install something you've compiled & installed locally: "The /usr/local hierarchy is for use by the system administrator when installing software locally." from https://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY https://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALH... So usr local could be fair game for whacking stuff in your firms base docker image that you then layer your firms product applications on top of. It'd be your unix engineering person putting stuff in /usr/local, not your app dev. "/opt is reserved for the installation of add-on application software packages." from https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC... Opt would be a better fit if we're sticking to the FHS. Think about what you'd usually install in /opt, maybe your veritas binaries. Maybe your AV solution. Maybe your ERP software product. etc. etc. Opaque binaries you got from a vendor. That's a better match for an application product you're shipping - which is what you're doing with the second docker image (the bit starting "from scratch") in the article's example dockerfile. That said, the FHS evolves based on conventions and /app for docker containers has become a convention. I wouldn't oppose just using /app but i do oppose chucking everything in /usr/local - it's a misguided attempt to preserve convention without grasping the convention.