raskrebs

Good point

Ahhh yes sure, but not too worried about that i think. Its not so difficult to create, but to innovate and maintain requires participation. It can be the bulk of the job. But most def its sad if people leave their good ideas in a fork of their own. But also great that you can reproduce a good idea thats been conflated with wayy too much crap, because a product lost site of ehat their value proposition was

Great to hear! Please add any issues or feature request if you find anything missing :)

I quite like go for how lean it is, really nice for local projects with lots of constant changes. Also easy to learn. The biggest most annoying thing is how bad error handling is done, not sure why they built it like that.

I primarily write typescript and python for work. But have dabbled in bunch of other languages at different jobs and for different tasks. Yet to pick up rust, but have been wanting to. But tend to pick what seems most right for the task, while also considering what i most want to be working with

Have a look at this issue, and the picture i posted. Their is an explanation on how to test it out locally if you wish too

https://github.com/raskrebs/sonar/issues/15

I looked around for a while, couldn't find anything. Someone posted about killport but never stumbled upon it. Has some features that are the same, but not all. From the reaction online people don't seem to know of other solutions like this, or have something they have made them selves in the .zshrc :)

Will have a look. Mind creating an issue so i don't forget?

https://github.com/raskrebs/sonar/issues

What sucks? Software distillation? :)

You can add PID with the c-flag, e.g.

sonar list -c port,process,pid,type,url,container

or just show all columns:

sonar list --all-columns

But yeah, it's quite cool. I believe the future lies in software distillation, so cool to see it happen on my own project :D

Probably not, that's what makes it so lean (it doesn't really pull in anything).

Although i have a feature branch with a tray app (for macos) that let's you monitor and track any process (will send notifications when one goes up or down). But it's just gimmicks i felt i needed to make life a bit easier when working with compose and across worktrees

I will, but the process is a bit tedious. But will look into it over the weekend

Someone else added an issue about this, and i replied explaining how to run the feature branch, have a look and please add any ideas to the issue:

https://github.com/RasKrebs/sonar/issues/15

Try and have a look at the readme, this adds a bit more functionality. Maybe some if it you'll find useful :)

Started with the same, but found my self wanting a bit more, so just built it

True, it was what it started as, but grew as i found my self missing features. Got a few users and now i don't want to update the name. Also easy and quick to write in the terminal

I think a cli tool that detects objects beneath the surface is a pretty intuitive name, but i was also reluctant in the beginning. But they are pretty keen on always using the qube part, i believe theirs is sonar-qube.

I get that, i also often install some and forgot about them. But i felt that there was a big gap in managing multiple services running on localhost. It's pretty lightweight if that helps

Any features you are missing or ideas for the use case?

Exactly, really hates it as well. Please post any issues you may have

I have added quite a lot of functionality beyond listing and killing ports. Please check out the readme, it may convince you to try it out.

Glad to hear! Please join the party and post any issues you have.

Good point. Could you add an issue, then i'll have a chance to look into it :)

https://github.com/RasKrebs/sonar/issues

Will check it out

Developers are nitpicky, atleast i am and i know a lot of others that are as well. So don't underestimate the value of a nice tool with good developer experience, one that's intuitive, clean and easy to use means a lot when juggling so many things during a workday. So having a clean and light implementation to make job even easier is in my opinion worth it (and thus needed) :)

True, but as i write their are workarounds, the problem is that they are unintuitive, difficult to remember and don't provide all that much usability beyond listing. So these lack useful features like getting process stats, killing ports easily without having to remember the the pid after lsof and so on. I often have to kill multiple process at once after a failed cleanup. If you are into agentic coding, then having your agent create a profile for all the processes it stats, which it can easily kill of when finished is a lot easier for me atleast.

Some features on the way are: next available port; wait (wait for a host to return a successful health check before proceeding - good for migrations etc.). And lots more. It's not just about listing running ports, but a tool for managing them.

But to each their own, that's what's lovely about the many options available. But if you have anything in relation to this you think is neat, feel free to open an issue. It may be able to convince you that a simple alias won't suffice.

Glad to hear! Have quite a few ideas in mind so keep an eye out for some updates (one of the ideas is an easy update command). There's a couple of open enhancement ideas as well. Feel free to add any or contribute.

I always have a bunch of local projects running, particularly during the weekend where I'm rarely working on one thing at a time. A big pain of mine was constantly running into port: Redis from one project blocking another, orphaned dev servers from old worktrees, Docker containers I forgot about. The usual fix is lsof -iTCP | grep ..., then figuring out what the PID actually is, then killing it. But I always forget the command, and it doesn’t really include all the information that I like.

So I built this lightweight CLI. Single binary, no dependencies. It shows everything listening on localhost with process names, Docker container info, clickable URLs etc.

Sure there are workarounds, but none that satisfied my need for a short, easily rememberable command. Also nothing really has the same satisfaction as running sonar kill 3000 — it just feels nice. I’ve already been approached by a few agent orchestration tools that have been struggling with the same thing. It's really useful when you have multiple agents running, but it's not built for just that use case, I have also find it handy when killing off all containers after a failed cleanup and so on. Also know that MCPs are dead and CLIs are the new thing in agentic coding, this might be a useful tool for Claude, particularly when a compose process exits before all containers are stopped.

Open for contributions, ideas and feedback.