←back to thread

65 points nickpapciak | 2 comments | | HN request time: 0s | source

Hey HN! We’re Abhi, Venkat, Tom, and Nick and we are building Datafruit (https://datafruit.dev/), an AI DevOps agent. We’re like Devin for DevOps. You can ask Datafruit to check your cloud spend, look for loose security policies, make changes to your IaC, and it can reason across your deployment standards, design docs, and DevOps practices.

Demo video: https://www.youtube.com/watch?v=2FitSggI7tg.

Right now, we have two main methods to interact with Datafruit:

(1) automated infrastructure audits— agents periodically scan your environment to find cost optimization opportunities, detect infrastructure drift, and validate your infra against compliance requirements.

(2) chat interface (available as a web UI and through slack) — ask the agent questions for real-time insights, or assign tasks directly, such as investigating spend anomalies, reviewing security posture, or applying changes to IaC resources.

Working at FAANG and various high-growth startups, we realized that infra work requires an enormous amount of context, often more than traditional software engineering. The business decisions, codebase, and cloud itself are all extremely important in any task that has been assigned. To maximize the success of the agents, we do a fair amount of context engineering. Not hallucinating is super important!

One thing which has worked incredibly well for us is a multi-agent system where we have specialized sub-agents with access to specific tool calls and documentation for their specialty. Agents choose to “handoff” to each other when they feel like another agent would be more specialized for the task. However, all agents share the same context (https://cognition.ai/blog/dont-build-multi-agents). We’re pretty happy with this approach, and believe it could work in other disciplines which require high amounts of specialized expertise.

Infrastructure is probably the most mission-critical part of any software organization, and needs extremely heavy guardrails to keep it safe. Language models are not yet at the point where they can be trusted to make changes (we’ve talked to a couple of startups where the Claude Code + AWS CLI combo has taken their infra down). Right now, Datafruit receives read-only access to your infrastructure and can only make changes through pull requests to your IaC repositories. The agent also operates in a sandboxed virtual environment so that it could not write cloud CLI commands if it wanted to!

Where LLMs can add significant value is in reducing the constant operational inefficiencies that eat up cloud spend and delay deadlines—the small-but-urgent ops work. Once Datafruit indexes your environment, you can ask it to do things like:

  "Grant @User write access to analytics S3 bucket for 24 hours"
    -> Creates temporary IAM role, sends least-privilege credentials, auto-revokes tomorrow

  "Find where this secret is used so I can rotate it without downtime"
    -> Discovers all instances of your secret, including old cron-jobs you might not know about, so you can safely rotate your keys


  "Why did database costs spike yesterday?"
    -> Identifies expensive queries, shows optimization options, implements fixes

We charge a straightforward subscription model for a managed version, but we also offer a bring-your-own-cloud model. All of Datafruit can be deployed on Kubernetes using Helm charts for enterprise customers where data can’t leave your VPC. For the time being, we’re installing the product ourselves on customers' clouds. It doesn’t exist in a self-serve form yet. We’ll get there eventually, but in the meantime if you’re interested we’d love for you guys to email us at founders@datafruit.dev.

We would love to hear your thoughts! If you work with cloud infra, we are especially interested in learning about what kinds of work you do which you wish could be offloaded onto an agent.

Show context
mdaniel ◴[] No.45111927[source]
I've always heard the theory that if you're not ashamed of your launch announcement then you've launched too late, but a page with just "Book a Call" is stretching the plausibility for who could possibly be in the target demographic

I know dang is going to shake his finger at me for this, but come on.

Also:

> AWS emulator

isn't doing you any favors. I, too, have tried localstack and I can tell you first hand it is not an AWS emulator. That doesn't even get into the fact that AWS is not DevOps so what's up: is it AWS only or does it have GCP Emulation, too?

That's my whole point about the leading observation: without proper expectation management, how could anyone who spots this Launch HN possibly know if they should spend the time to book a call with you?

replies(1): >>45112184 #
1. dang ◴[] No.45112184[source]
I'm not sure I understand the criticism here, but let me try to address what I think you (might?) mean, and I hope it doesn't come across as shaking a finger!

You're right that the bar is higher for Launch HNs (I wrote about this here: https://news.ycombinator.com/item?id=39633270) - but it's not uncommon for a startup to have a working product and real customers and yet have a home page that just says "book a call".

For some early-stage startups it makes sense to focus on iterating rapidly based on feedback from a few customers, and to defer building what used to be called the "whole product" (including self-serve features, a complete website, etc.) until later. It's simply about prioritizing higher-risk things and deferring lower-risk things.

I believe this is especially true for enterprise products, since deployment, onboarding, etc. are more complex and require personal interaction (at least in the early stages).

In such cases, a Launch HN still makes sense when the startup is real, the product is real, and there are real customers. But since the product can't be tried out publicly, I tell the founders they need a good demo video, and I usually tell them to add to their text an explanation of why the product isn't publicly available yet, as well as an invitation to contact them if people want to know more or might want to be an early adopter. (You'll notice that both of those things are present in the text above!)

replies(1): >>45122639 #
2. mdaniel ◴[] No.45122639[source]
I suspect I am just predisposed to not wanting to watch a video of anything, because it usually has a very low bitrate of knowledge transferred per investment of my time, which is ironic given the actual bandwidth requirements of video. In this specific case it did turn out to actually help me by pointing to the actual PR that their bot made <https://github.com/datafruit-dev/terraform-demo/pull/26/file...> and/or <https://github.com/datafruit-dev/terraform-demo/pull/27/file...> so I can know for sure that I am not a good fit for this product

However, I would not have learned that they seem to offer GCP, too, from the website; I only learned that from the video. That is my complaint: how hard would it have been to include "AWS or GCP" on the page? Or, if nextjs doesn't support arbitrary text for some reason, then including those 3 letters in the textarea here would have gone a long way, too

I know this is a ton of words, and that I'm barking up the wrong tree by telling you about my sadness about the lack of specificity from a Launch HN. But you asked to understand, and I knew from prior experience that either YC, or the mods, or both, are super sensitive to having any Lanuch HN criticized so I knew this conversation was coming. I do hope that I presented my observations in a factual and [mostly] neutral albeit frustrated tone (err, except for the "come on" ... I do regret that I included that part)

But based on your response I'm guessing I'm just not in the target demographic of what a Launch HN should offer to folks who read them. I can only say that I'll try harder to keep my feedback to myself, despite almost all of them ending with "We would love to hear your thoughts!" So, I guess it's closer to someone saying "how are you?" in the morning