For development, I’ve found containers to be useful for “arms-length” daemons (that is: databases and similar) as the containers need not change often. It makes

For development, I’ve found containers to be useful for “arms-length” daemons (that is: databases and similar) as the containers need not change often. It makes it easier to ensure that every project uses the correct version of these daemons, as sometimes the OS package manager may not offer the correct version, or different projects necessitate running different versions simultaneously. As for everyday running of the actual software you’re writing: no way. The tooling for integrating an editor or IDE with the container process is pretty poor (so one often ends up just setting up everything on the host anyway), image rebuilds are frequent and slow, and most language ecosystems already have tools for installing and switching between different versions. They are useful if you want to more closely replicate your CI or production environment for specific debugging, though. Nevertheless, the belief that running a container locally will “never create disparity between your development environment and your production environment” is a farce. There are so many other variables that are often still different. It helps, but it’s far from a silver bullet.