Nuphos
The AI-Native DevOps Workspace.
745 followers
The AI-Native DevOps Workspace.
745 followers
Nuphos gives engineering teams a shared environment where AI agents can learn your infrastructure, investigate issues, and operate production systems.
Interactive
Free Options
Launch Team
World model AI : Sharm SEKAISimulate your idea on a living world.
Promoted
Hey Product Hunt 👋 Yuanlin here, founder of Zeabur and now building Nuphos.
Nuphos started from something we learned while building Zeabur.
We used to describe where Zeabur was going as “Your AI DevOps Engineer.”
But eventually we realized:
A PaaS asks you to adapt to its rules. A DevOps engineer adapts to your team’s infrastructure.
They learn the systems you already have, work within your permissions, and follow the way your team operates.
AI DevOps engineers should too.
Nuphos is an AI-native DevOps workspace that brings AI agents into the infrastructure your team already runs, without giving up control.
Our team of fewer than 10 engineers operates across 8+ clouds, 20+ Kubernetes clusters, and more than 10,000 hosts. We’d already been using coding and terminal agents in production, and they were surprisingly capable.
The hard part wasn’t getting an agent to run kubectl or inspect logs. It was everything around the action:
Whose permissions is it using?
What can it change?
Who approved it?
What exactly changed?
That’s what we built Nuphos around.
With Nuphos, you can connect your existing AWS, GCP, Kubernetes, and observability stack, keep agents read-only by default, require approval for write actions, and keep the context and audit trail shared with your team.
You can try it with your own infrastructure, or use the live demo on our homepage without signing up.
🎁 Use code PH100OFF to get your first month of Nuphos free.
👉 Got questions or want to follow what we’re building? Join our Discord: https://nuphos.ai/dc
And I’d love to hear from people running production:
What kind of experience would make an AI feel like a real DevOps engineer on your team, rather than just another AI agent?
Congrats on the launch!
Really interesting to see agents operating directly against customer infrastructure.
How do you evaluate whether an agent will make the right infrastructure decision across scenarios it hasn’t encountered before, especially failures that would be expensive or risky to reproduce in a real cloud environment?
@mathsociety We believe that human-in-the-loop process is still a must, even with us dogfooding Nuphos ourselves. The way we collaborate with Nuphos agent is read-only mode and plan-then-approval method. Context and knowledge across our SREs are still the ultimate guardrail.
p.s. we use Nuphos to manage our stack across multiple vendors and set up cron job and alert to track costs.
@lingwu05 Makes sense.
Keeping the SRE in the loop is probably the right move today. I think confidence is still the big hurdle when it comes to giving agents more autonomy over infrastructure.
What I’m curious about is what happens before it gets to them. Have you tried letting the agent run through simulated failures or infra scenarios first, just to see what decisions it makes before an SRE has to review the plan?
@mathsociety Actually I might not be the best fit for this question. But as the growth marketer at Nuphos I did witness how my fellow SRE colleagues interact with our agent, simulating scenarios with agent and without agent. (aka the quality check of the agent result)
I'd say yes we do run A/B test on similar situation and to see how confident we are with the suggested plan proposed by Nuphos agent.
@mathsociety Great question. We can’t realistically reproduce every expensive or risky infrastructure failure. From the engineering side, we make the agent’s investigation auditable, what it checked, what it inferred, and where uncertainty remain, while keeping risky changes behind explicit plans and approvals. We also use traces from our own dogfooding to turn concrete failures into targeted safeguards and tests.
@bruce_du That’s exactly the gap I’ve been thinking about. The trace → test loop makes sense once you’ve already seen the failure.
But what about the stuff you haven’t seen yet? If the agent could run into those failures in a simulated cloud first and actually work through them, would that help you build more confidence in Nuphos before it hits the real thing?
@mathsociety A simulated cloud could definitely help improve how the agent investigates unfamiliar failures, although we don’t have that evaluation layer today. But our safety model doesn’t depend on the agent having seen every scenario beforehand, it can continue investigating through read-only operations, while mutations default to human approval unless the user has explicitly pre-authorized a narrow class of actions. Larger or destructive infrastructure work is presented as a plan before execution.
@mathsociety Great question. We don’t assume an agent will always make the right call in a scenario it hasn’t seen before.
We separate evaluating the reasoning from trusting the execution: replay incidents and seeded failure scenarios where we can, then in production require the agent to show its evidence, propose a scoped plan, and verify the result after execution.
For failures that are too expensive to reproduce safely, the goal is less “prove the model is always right” and more “make sure being wrong doesn’t automatically become a production incident.”
That’s also why approval and permission boundaries matter so much to us.
@mathsociety @yuaanlin +1 to this. I’d also frame simulation as an evaluation layer, not the whole safety model.
It can help us test how the agent investigates unfamiliar failures, but production trust still needs evidence, uncertainty reporting, scoped permissions, and approval boundaries. The goal isn’t “the agent has seen everything before” — it’s “even when it hasn’t, the blast radius is controlled.”
@mathsociety Great question. We don’t assume the model will always make the right call in an unfamiliar situation. Only actions we can confidently classify as read-only can proceed automatically. Anything sensitive or potentially destructive requires the agent to present a clear plan for human review and approval before execution, with scoped credentials and a full audit trail.
This looks promising. I would be curious to see how Nuphos handles situations where the agent is unsure or finds conflicting signals. Knowing when to pause and ask a human could be just as important as knowing what action to take.
@carlvert On point! The guardrails and read-only access are the default mode (and our suggested way) for Nuphos agent. We believe that Trust is earned through approvals, and the human-in-the-loop process is a must! Think of it as an intern to your SRE team!
@carlvert Completely agree. We consider “knowing when to stop” part of agent correctness, not a failure mode. When signals conflict, Nuphos should surface the evidence and uncertainty, ask for clarification where needed, and avoid crossing from investigation into mutation without explicit approval.
@carlvert Absolutely. We think uncertainty should be a first-class state, not something the agent tries to hide.
If the evidence is conflicting or the agent doesn’t have enough confidence, it should surface what it knows, what’s unclear, and ask a human before taking the next step.
Knowing when not to act is a big part of being trustworthy in production.
@carlvert Absolutely. In Nuphos, uncertainty is a reason to pause, not to guess. If an action can’t be confidently classified as safe and read-only, the agent presents a plan and asks for human approval before proceeding.
@carlvert Absolutely, and we agree. In production, knowing when not to act is just as important as finding a likely fix.
Nuphos is read-only by default.
When signals conflict or the evidence isn’t strong enough, the agent should surface what it found, explain the uncertainty, and ask for human input rather than forcing a confident answer.
Any proposed change is shown as a plan and still requires approval before execution.
This is also an area we’re actively testing, so we’d love to hear about the messy edge cases you think we should try.❤️
the read-only-by-default plus approval-for-writes model makes sense for trust. during an active incident when minutes matter, does that approval step ever become the bottleneck itself, or is there a break-glass path for that moment?
@sabber_ahamed Yes, very precisely put, appreciate the depth of the question. When SREs are on-call during the middle of the night or when the cost spiked up without further context all of a sudden, honestly this is actually what we are still processing internally at Nuphos, and yes our SREs are sometimes complaining about the guardrails. Our current act is to reflect on the shared team context and update it with the preferred human-in-the-loop process.
(on the other side we're glad that we're not frequently on call lol)
@sabber_ahamed You’re right, the approval step can become a bottleneck. Today, we don’t have a universal break-glass bypass, and that’s intentional. Teams can define scoped auto-authorization for expected operations, while unfamiliar or high-impact changes still pause for a human. Finding the right boundary is something we’re actively refining from our own operational use.
@sabber_ahamed Yes, that tradeoff is real.
That’s why Nuphos has Auto Mode. You can define your own authorization policies ahead of time, and if an action matches those policies, the agent can execute it automatically without asking for approval.
Higher-risk actions can still stop and wait for a human.
The idea is to decide the boundary before the incident, instead of figuring it out at 2am.
@sabber_ahamed That’s a great question, and the tradeoff is real. Approval can add latency, but that’s a policy-design problem—not a reason to remove controls. Teams can pre-authorize well-understood, low-risk incident actions, while anything outside that boundary still requires approval. The goal is fast response within clear limits, not speed at any cost.
Really interesting approach. How does Nuphos learn the context of a team’s infrastructure over time? For example, can it pick up internal runbooks, past incidents, and team-specific operational conventions?
@abby_mao1 Yes, that’s exactly the direction.
Nuphos builds shared memory from past investigations, incidents, and the context your team gives it, so the next session doesn’t start from zero.
We also want it to learn team-specific runbooks and operational conventions over time, so it behaves less like a generic agent and more like someone who already knows how your team runs production.
@yuaanlin Appreciate the thoughtful answer! Building on past investigations instead of starting fresh every time feels like a really important step toward making the agent part of the team. Best of luck with the launch!
Quesstion: Who is the ideal cstomer here? Who do you solve this for? With which customer does this fit the best?
@conduit_design Great question. The best fit today is engineering teams that already run real production infrastructure, but whose operational context is spread across too many places: cloud consoles, Kubernetes, logs, dashboards, Slack threads, runbooks, and people’s heads. Nuphos is especially useful when a team has multiple services, on-call responsibilities, or infra across more than one cloud/tooling stack. The pain we solve is not just “run a command with AI” — it’s helping the team investigate, understand context, propose safe actions, and keep a shared record of what happened. Solo builders can still get value, but our strongest fit right now is teams where production reliability, permissions, approvals, and shared incident context already matter.
@conduit_design Great question. Our best-fit customer today is a small to mid-sized engineering team already running real production infrastructure across things like AWS/GCP, Kubernetes, and observability tools.
Usually they have enough complexity that incidents, permissions, cloud cost, and operational knowledge are starting to become painful, but not enough DevOps/SRE headcount to throw people at every problem.
That’s where Nuphos fits best: teams that already have production complexity and want an AI teammate to understand and operate within the stack they already use.
We use AWS significantly more than GCP, mainly to avoid the learning curve associated with GCP. This tool looks like it can help lower the learning curve for operating new platforms. Right?
@siningio Exactly! That’s one of the use cases we’re excited about.
Nuphos brings AWS, GCP, and Kubernetes into the same workspace, so the agent can help you understand unfamiliar resources, map dependencies, and plan changes or migrations using the context of your existing setup.
It won’t replace platform knowledge entirely, but it can make the first steps much less intimidating.
We’d love to hear how it works with your AWS-heavy stack!
@siningio Yes, exactly.
One of the things we want Nuphos to do is reduce the operational learning curve when your stack expands into a platform your team knows less well.
Instead of learning every console and command from scratch, you can ask Nuphos to inspect the environment, explain what it’s seeing, and help you operate it using the context from your existing infrastructure.