That’s a great approach! I’d be intrigued to see how you deal with config -if I have an app that has environmental config e.g. for a mongo endpoint, and I select my config based on my environment, I’d expect different URLs for TEST and PROD. If I build my image with NODE_ENV=production and use that ENV to control my config, it’d get the production config which I don’t want. If I build my image with NODE=production, but set NODE_ENV to something else when I run the container for testing, that could cause problems as other packages may expect dependencies which aren’t there. That being said, there’s many ways to work around that and I like your approach as it saves building the image twice.