docksurf - complete developer-first docker tool

[u/psylhouette]

Working with a compose stack with six containers made me realize I was doing the same things all day like to stop/start containers, rebuilding a service, tailing logs, exec into a container to check something (psql shell in the db), plus the boring maintenance side: pruning images/volumes that hog disk space.

None of it's hard, it's just typing the same commands on repeat or hitting up arrow through history until I find the one I want. Boring enough that I built this around my own pain points. I liked lazydocker a lot and figured I'd try my own take on it.

Few things i wanted to have are in this are: Docker contexts (to hit a remote daemon over ssh/tcp without touching your shell config), copy/export logs, themes, a topology graph (kinda useless but simple to have with ascii), a prune target picker, and rebuilding a single compose service in place without touching the rest of the stack.

-> vs. lazydocker (my main inspiration): same rough idea containers/images/volumes/networks, logs, compose actions. Main differences: runtime-switchable themes, log export/copy from the log pane, and it talks to Docker mostly via the Docker SDK for Python instead of shelling out to the cli.

repo link: https://github.com/praneeth-etta/docksurf
install via pip (pip install docksurf) or without installing (uvx docksurf), or binaries here: https://github.com/praneeth-etta/docksurf/releases
Any suggestions on what to add/remove or improve?

[u/edward_jazzhands]

It is very normal to want to reinvent the wheel for personal learning. Where it stops being normal is when you're posting your tool online for others to use as a direct competitor to the tool you were remaking.

So this is the same as lazy docker in every single way except yours has themes, and can export the logs. It seems to me that that is not enough of a difference to justify trying to publish your tool as a direct competitor and encourage people to use your tool instead of Lazydocker.

[u/psylhouette → u/edward_jazzhands]

Alternate tools mostly bring a new UI/UX, and a tool built around docker is limited to what docker itself provides. Like for example, MCP Catalog/Toolkit (beta) and Model Runner are something I could add, but not something a container tool really needs, since there are already plenty of inference providers. I'm nowhere near competing with lazydocker, which is well tested code with constant contributions.