Usually yes. It's not that much complexity in and of itself, although how you use it could affect that (eg docker compose-- I prefer a big fat docker image to a

Usually yes. It's not that much complexity in and of itself, although how you use it could affect that (eg docker compose-- I prefer a big fat docker image to a fleet of interconected ones for the same reason static linking beats dynamic by default -- it may perform less well, but you can optimize for that later if you need it, but deployment and consistency is easier for static linking) But like, if you don't need it, you don't need it. It depends on what you're doing. If you have multiple runtime dependencies, it will help a lot. If your target is a single static executable (eg you use golang or java with a all-in jar target) and no runtime dependencies like a database (or even if your only runtime dep is a single SQL database connection or just a single JVM runtime and your only hassle is documenting the correct JVM version to use) then it may not be adding that much value especially early on. Never found it too hard to add it, either. A Dockerfile is a glorified shell script so if you have a README for installing the whole mess on a normal machine, following that README again (and as always, finding how inaccurate it is lol) is all you really need to do. For the typical enterprisey legacy project with over a dozen runtime deps and micro and macro (lol) services all over... yeah, it helps a ton to avoid tons of version hell deployment works-on-my-machine drama. It was so nice when it started coming out back in the early teens -- so much so, that it was worth using for all nonprod even when it was still super flaky and not suitable for production yet (eg remember how bad its disk space leaks used to be and how you needed to script that yourself?)