Look, I think this might just be a little bit premature. Claiming that it's secure and fast because it's locally hosted is not convincing at all. "Secure" isn't convincing because you're asking me to run three docker containers worth of random code, and trust that random code with API keys/credentials to all my critical infrastructure. I have no way to know what your security practices inside those containers are. "Fast" isn't convincing either, with the need to run redis and mongoDB inside local docker containers being particularly unconvincing. The fact that there's no documentation at all (or at least, none that I could find) is the cherry on top.
Plus, what's up with only supporting running the containers on MacOS? That's really, really bizarre.
Basically, there are a number of signals here that prevent me from trusting you enough to even consider trying this out, even though it's quite possibly solving an interesting problem.
Hey Nitish here from the Kloudi! First of all thank you for your feedback.
Answering some of the questions you have asked.
- We are a small 2 people team so our approach has been to first get Kloudi out in the open and then figure out what parts of the code we want to open source and what licensing we need to have around that. But irrespectively if you find any security concerns, please feel free to reach out on nitish@kloudi.tech and we'll try to get it sorted as soon as we can. Also keep an eye out on https://www.github.com/kloudi-tech/ for more updates on this.
- Adding to your point on security, we keep all the keys to the tools that you connect with on your local system stored in Mongo hence a container for that. We use a Redis cache to speed up the response time for API requests hence another container for that.
- Documentation are WIP but meanwhile you can read some of the stuff that we have written on https://kloudi.substack.com/
It's more around our journey of building Kloudi, the problem and how we are planning to solve for it. Like I said before we are a very small team and documentations are WIP.
- Finally, we are only supporting macOS as of now because our electron based app currently runs only on this platform. We plan to gradually release support for other platforms eventually but till then we it is macOS.
The biggest thing is about trust: you can tell me that you're following good security practices with my keys, but I don't have a good reason to believe you, and the signals you're giving off all point in the wrong direction.
jart's finding (in another comment below) that you're using fullstory in your electron app is probably the most damning; at this point I wouldn't ever consider even trying your product. Putting a keylogger in an app like this is evidence of careless engineering at best, and malicious intent at worst. Either one is disqualifying for a tool that would have access to so much of my critical infrastructure.
We have built it for developers and understand the criticality of the data handled by the tools used by developers. We in no way want to give off an impression of mistrust or carelessness at the very least, but this sentiment seems to be resonating through out the comments section and as an immediate fix we have updated our app to have no fullstory in it .
Would it be possible for you help us pioneer these concerns. We are here to listen and work on it and would love to chat on our discord channel or over email. Thank you in advance!
Just to add to that, on self-hosted mode now you are responsible for an data infrastructure which you really didn't need before as the data was owned by the other SaaS providers.
It's a closed source, proprietary app that has spyware disclosed in the TOS (section 6.4). The method of installation is mostly irrelevant in light of that.
In short, you need to be careful how you package and distribute software (including updates) for a couple reasons related to security. Many distributors doesn't do it properly, but thankfully companies such as Apple and Microsoft are starting to be more strict about what you can run on their operating systems, requiring the developer to notarize the application, or have to ask the user to by-pass the safety mechanism.
Hey folks! Nitish and Sneh here from Kloudi (https://kloudi.tech). We are building a Universal Command Line that enables developers to enter commands and queries to search, view and perform actions on data from all their engineering tools. Some of the tools that we currently support out of the box are Sentry, Github Issue, Jira, Datadog, Rollbar, AWS etc.
Kloudi was born as a solution to the problems faced by us while running our previous startup which was a managed freelancer marketplace. While freelancing and handling development for a lot of startups at a given time we realised that any other engineering team uses on an avg 10-15 tools to monitor various aspects of a developers workflow however there is still a lot of staggered information that any developer spends time knitting together. This continued problem was what became the trigger point for building Kloudi. We currently support tools like Sentry, Rollbar, Datadog, Github Issues and our planning to provide support for a bunch of dev-tools in the future.
Some of the key things about Kloudi is that it is locally hosted on your systems. Which means all the keys and data reside on your system. Making it 100% secure and extremely fast!
We are still in our early days of building the product and would love for you all to take it out for a spin and give your feedback. Cheers!
I tried to email this to you privately, but hello@kloud.team bounced and you don't have any other public contact info.
Your docker image (kloudi/api) has a whole bunch of credentials in plaintext inside it. I am not going to check whether they're valid or not, but they certainly look real.
Hey Nitish here!
Those are application keys of some of the vendors we are integrating with. In our next update we plan to figure out a way to mask them.
Feedback: Having a GitHub repo full of compiled binaries, with no source code, and no license provided (as far as I can tell, this is closed-source, proprietary software, yes?) is somewhat misleading.
It should be clear from looking at your website that you are not free software. It's not clear at all.
Kloudi uses FullStory in its Electron GUI too! https://justine.lol/kloudi.png If anyone's wondering, FullStory is basically a keylogger that gives you the godlike ability to spy on your users in real time. https://www.fullstory.com/blog/want-to-co-browse-with-your-c... We live in a creepy orwellian world. It amuses me that the authors of this "command line" thought they could fool Hacker News.
Here's my two cents. I wouldn't care about jumping through few services. In certain cases you will also have single sign-on enabled so multiple tools is not a problem. Let's say I have n platforms I am using. Now I use kloudi, now I have to managed n+1 platform. I don't see an inherent value of this platform that would pull me towards using this platform long term. I will always be afraid that you will always have one-off integration issues.
The value add I see is having a consistent interface to all your tools through the CLI.
When your entire workflow is CLI based, having access to your tools from the CLI is really valuable. Unforutunately, I'd wager that the people that this applies to are the first to write their own wrappers for their tools to fit their exact workflows.
This would have been interesting for me, if I hadn't already gone through the effort of writing a bunch of jira/confluence/bitbucket/jenkins CLI wrappers.
Plus, what's up with only supporting running the containers on MacOS? That's really, really bizarre.
Basically, there are a number of signals here that prevent me from trusting you enough to even consider trying this out, even though it's quite possibly solving an interesting problem.