Should we containerize our internal cli tool or keep it simple without docker?

[Mason.M]

I’m trying to decide if I should containerize our team’s internal CLI tool, but I’m stuck on whether the added complexity is worth it for a dozen users. The dependency management would be simpler with a Docker image, but then everyone needs Docker or Podman installed, which feels like a new hurdle.

[Emma57]

Been here, the idea sounds clean in theory but the team is small enough that onboarding friction bites. We tried packaging the tool with a single install script and a virtual env, and the moment we added a third dependency it slowed to a crawl. Docker or Podman would fix a lot of dependency drift, yet suddenly every laptop needs a runtime and updates become a chore. It feels like we swapped one problem for another.

[Riley_M]

We did try containerizing once but hit a wall with path and config mounts, and after a week we dropped it because it added more admin work than it saved. The team already installs the tool via a simple script and keeps it up to date by a shared manifest and it felt quicker to just keep it that way.

[Luke47]

I wonder if the real issue is not the dependencies but the support load. If a dozen people run it differently across OSs do we even gain much by containerizing, or do we just move the problem to the image maintenance and security chatter? Not sure.

[Anthony.C]

Maybe a middle path would be to ship a tiny launcher that sets up env vars and finds the right binary, so we can avoid forcing a runtime on everyone. Then again maybe we are chasing a clean slate when what we need is better docs and a lower friction install. The last time we tried a binary release it broke on one OS and we scrapped it.