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?
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.
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 really exciting! One thing I’m curious about: how would you see Nuphos fitting into the workflow of a solo developer or a one-person team?
I build and experiment with multiple small products and AI projects, but I don’t necessarily have a large SaaS infrastructure or a dedicated DevOps team.
Would Nuphos still be useful at this stage? If so, what would be a good real-world use case for someone like me to start with?
Or is Nuphos currently more suited to larger teams that already have a fairly complex production infrastructure?
Would love to understand where a solo builder fits into the Nuphos vision.
@timliao Great question. I’d say Nuphos becomes more valuable as your infrastructure gets more complex, but you definitely don’t need a dedicated DevOps team to use it.
For a solo builder, a good starting point is simply connecting the cloud/Kubernetes setup behind your projects and using Nuphos as one place to understand what’s running, investigate issues, and keep an eye on cost or reliability.
In fact, solo developers often have the opposite problem: there’s no DevOps engineer to ask when something breaks at 2am.
That said, our strongest use cases today are teams already running real production infrastructure across multiple services or tools. That’s where the shared context, approvals, memory, and cross-stack investigation become much more valuable.
@timliao Definitely. As a solo builder, you still have infrastructure—you’re just wearing both the developer and operator hats. A good starting point is to connect one cloud account read-only and ask Nuphos to inventory what’s running, explain an unexpected cost, or investigate a failing deployment; any changes can remain approval-gated. Larger teams benefit from shared context and collaboration, but they aren’t a prerequisite.
@timliao Love this question! Honestly, solo devs might get the most out of it — the whole idea is that you don't need a DevOps team, because Nuphos kind of is your DevOps team.
If you're running a few side projects, infra work still lands on you — deploys, random 2am crashes, digging through logs. Just connect a cloud account or cluster you already have, and when something breaks, tell the agent — it checks logs, looks at the deployment, and suggests a fix. Basically an on-call engineer for projects that would never justify hiring one.
So definitely not big-teams-only. Curious what your stack looks like though — happy to point you to a good starting spot!
@timliao Thanks, Tim — great question. Solo builders are very much part of the Nuphos vision.
You don’t need a large infrastructure or a dedicated DevOps team to benefit. In fact, when you’re building alone, every hour spent switching between deployment dashboards, logs, cloud consoles, and infrastructure tools is time taken away from the product.
A practical starting point would be using Nuphos to manage and understand the production environment for one of your small apps: seeing what’s running, keeping operational context in one place, and investigating deployment or infrastructure issues without having to become a DevOps specialist.
Larger teams naturally get additional value from shared context and collaboration, but for a solo developer the core benefit is leverage—being able to operate several products with less overhead and more confidence.
We’d love to learn more about your setup as we continue shaping the solo-builder experience.
@timliao The real dividing line isn’t team size—it’s how much infrastructure you’re responsible for. A solo developer running production workloads across cloud services, databases, or Kubernetes is already a strong fit. You’re still doing platform work; you’re just doing it without a platform team.
Report
The point that running kubectl or inspecting logs was not the hard part really stood out to me. We already know agents can execute commands. The real challenge is whether a team can trust them in production. Permissions, approvals, and a clear record of what changed are what turn a capable agent into something an engineering team can actually work with. Congrats on launching!
@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.
Report
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?
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.
Report
@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!
Coming from the marketing side of the team, I’ve been preparing for this launch for a long time. I’ve watched Nuphos take shape through every piece of copy, every image, and every video we created.
The living runbook is probably the feature I’m most excited about. Too much valuable incident knowledge gets buried in Slack, only to be rediscovered at 2 a.m. months later.
So happy to finally see Nuphos live 🎉 Give it a try! We’d genuinely love to hear any feedback, especially what feels wrong or where it breaks.
I’m one of the platform engineers building Nuphos, what concerns me the most is how each infra team adopt our product. I'd love to see the most brutal, realistic way on how every other SREs would use Nuphos. 🙂
Interrupt the agent mid-run, change direction, reject its plan, don't go easy on us. This is exactly how we dogfood and use Nuphos on our infra from day to day. We'd appreciate feedback, apart from just a simple "looks good".
I worked on the approval gate feature. There were a lot of internal debates around how much context to show, when to ask for approval, and what happens if someone interrupts halfway through. Would love feedback from people who deal with production systems every day.
Report
The point about running kubectl not being the hard part really resonated with me. Agents can already execute commands. The bigger challenge is making sure teams understand what they are doing and feel comfortable giving them access to production. Nuphos seems to be solving the right problem.
@luke_pioneero Glad to hear this! The way we address the Trust issue is through the default read-only first access. We believe that trust is earned and the human-in-the-loop process is a must.
@luke_pioneero Exactly. As an engineer building Nuphos, I’ve found that executing the command is usually the easy part. The harder part is showing the evidence, assumptions, and proposed change clearly enough that an operator feels comfortable proceeding, especially in production. That trust boundary is a big part of what we’re building around.
@luke_pioneero Exactly. The command itself is rarely the hard part.
The real challenge is giving the agent enough context to make a good decision, while making its reasoning, permissions, and actions understandable to the team.
That trust layer is a big part of what we’re building with Nuphos. Thanks Luke!
@luke_pioneero That’s exactly how we think about it. Production access shouldn’t be an all-or-nothing leap. Teams should be able to start with visibility, see how the agent behaves, and gradually expand its authority as confidence grows.
Replies
Nuphos
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?
Cloud World Model
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?
Nuphos
@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.
Cloud World Model
@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?
Nuphos
@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.
Nuphos
@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.
Cloud World Model
@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?
Nuphos
@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.
Nuphos
@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.
Nuphos
@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.”
Nuphos
@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.
Minduck
This looks really exciting! One thing I’m curious about: how would you see Nuphos fitting into the workflow of a solo developer or a one-person team?
I build and experiment with multiple small products and AI projects, but I don’t necessarily have a large SaaS infrastructure or a dedicated DevOps team.
Would Nuphos still be useful at this stage? If so, what would be a good real-world use case for someone like me to start with?
Or is Nuphos currently more suited to larger teams that already have a fairly complex production infrastructure?
Would love to understand where a solo builder fits into the Nuphos vision.
Nuphos
@timliao Great question. I’d say Nuphos becomes more valuable as your infrastructure gets more complex, but you definitely don’t need a dedicated DevOps team to use it.
For a solo builder, a good starting point is simply connecting the cloud/Kubernetes setup behind your projects and using Nuphos as one place to understand what’s running, investigate issues, and keep an eye on cost or reliability.
In fact, solo developers often have the opposite problem: there’s no DevOps engineer to ask when something breaks at 2am.
That said, our strongest use cases today are teams already running real production infrastructure across multiple services or tools. That’s where the shared context, approvals, memory, and cross-stack investigation become much more valuable.
Nuphos
@timliao Definitely. As a solo builder, you still have infrastructure—you’re just wearing both the developer and operator hats. A good starting point is to connect one cloud account read-only and ask Nuphos to inventory what’s running, explain an unexpected cost, or investigate a failing deployment; any changes can remain approval-gated. Larger teams benefit from shared context and collaboration, but they aren’t a prerequisite.
Nuphos
@timliao Love this question! Honestly, solo devs might get the most out of it — the whole idea is that you don't need a DevOps team, because Nuphos kind of is your DevOps team.
If you're running a few side projects, infra work still lands on you — deploys, random 2am crashes, digging through logs. Just connect a cloud account or cluster you already have, and when something breaks, tell the agent — it checks logs, looks at the deployment, and suggests a fix. Basically an on-call engineer for projects that would never justify hiring one.
So definitely not big-teams-only. Curious what your stack looks like though — happy to point you to a good starting spot!
Nuphos
@timliao Thanks, Tim — great question. Solo builders are very much part of the Nuphos vision.
You don’t need a large infrastructure or a dedicated DevOps team to benefit. In fact, when you’re building alone, every hour spent switching between deployment dashboards, logs, cloud consoles, and infrastructure tools is time taken away from the product.
A practical starting point would be using Nuphos to manage and understand the production environment for one of your small apps: seeing what’s running, keeping operational context in one place, and investigating deployment or infrastructure issues without having to become a DevOps specialist.
Larger teams naturally get additional value from shared context and collaboration, but for a solo developer the core benefit is leverage—being able to operate several products with less overhead and more confidence.
We’d love to learn more about your setup as we continue shaping the solo-builder experience.
Nuphos
@timliao The real dividing line isn’t team size—it’s how much infrastructure you’re responsible for. A solo developer running production workloads across cloud services, databases, or Kubernetes is already a strong fit. You’re still doing platform work; you’re just doing it without a platform team.
The point that running kubectl or inspecting logs was not the hard part really stood out to me. We already know agents can execute commands. The real challenge is whether a team can trust them in production. Permissions, approvals, and a clear record of what changed are what turn a capable agent into something an engineering team can actually work with. Congrats on launching!
Nuphos
@sandy_liusy Exactly. Capability is only half the problem!
The harder part is making an agent a team can actually trust in production.
That’s why permissions, approvals, and a clear record of every action are such a big part of Nuphos.
Thanks for the thoughtful comment!
@yuaanlin Totally agree. You’re tackling the part that really matters for production teams. Excited to follow Nuphos!
DiffSense
Quesstion: Who is the ideal cstomer here? Who do you solve this for? With which customer does this fit the best?
Nuphos
@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.
Nuphos
@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.
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?
Nuphos
@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!
Nuphos
Coming from the marketing side of the team, I’ve been preparing for this launch for a long time.
I’ve watched Nuphos take shape through every piece of copy, every image, and every video we created.
The living runbook is probably the feature I’m most excited about. Too much valuable incident knowledge gets buried in Slack, only to be rediscovered at 2 a.m. months later.
So happy to finally see Nuphos live 🎉
Give it a try! We’d genuinely love to hear any feedback, especially what feels wrong or where it breaks.
Nuphos
I’m one of the platform engineers building Nuphos, what concerns me the most is how each infra team adopt our product. I'd love to see the most brutal, realistic way on how every other SREs would use Nuphos. 🙂
Interrupt the agent mid-run, change direction, reject its plan, don't go easy on us. This is exactly how we dogfood and use Nuphos on our infra from day to day. We'd appreciate feedback, apart from just a simple "looks good".
Nuphos
I worked on the approval gate feature. There were a lot of internal debates around how much context to show, when to ask for approval, and what happens if someone interrupts halfway through. Would love feedback from people who deal with production systems every day.
The point about running kubectl not being the hard part really resonated with me. Agents can already execute commands. The bigger challenge is making sure teams understand what they are doing and feel comfortable giving them access to production. Nuphos seems to be solving the right problem.
Nuphos
@luke_pioneero Glad to hear this! The way we address the Trust issue is through the default read-only first access. We believe that trust is earned and the human-in-the-loop process is a must.
Nuphos
@luke_pioneero Exactly. As an engineer building Nuphos, I’ve found that executing the command is usually the easy part. The harder part is showing the evidence, assumptions, and proposed change clearly enough that an operator feels comfortable proceeding, especially in production. That trust boundary is a big part of what we’re building around.
Nuphos
@luke_pioneero Exactly. The command itself is rarely the hard part.
The real challenge is giving the agent enough context to make a good decision, while making its reasoning, permissions, and actions understandable to the team.
That trust layer is a big part of what we’re building with Nuphos. Thanks Luke!
Nuphos
@luke_pioneero That’s exactly how we think about it. Production access shouldn’t be an all-or-nothing leap. Teams should be able to start with visibility, see how the agent behaves, and gradually expand its authority as confidence grows.