Launched on Product Hunt today: the part of shipping an AI-built app nobody automates — the server
A few weeks ago I posted here about the wall people hit after the AI finishes the app: it has to run on a real server, and that's SSH, a reverse proxy, HTTPS, a firewall, Docker, and a 2am outage you can't read.
Server Manager is live on Product Hunt today. You connect it to your own server with your own SSH login and say what you want — "put this app on my domain with HTTPS", "lock down the firewall", "the site's down, find out why" — and the agent does the server-side work. Before anything changes, it shows you the literal command and waits. Read-only checks just run.
Three people here shaped it more than any analytics did:
- nicominetti pushed the "inverse list" — after a check, say what you looked at AND what nobody looked at. Saying what a tool does NOT cover turns out to be the reassuring half.
- madmike said the pain isn't first setup, it's the second deploy — changing a box you'd already declared done, and proving from outside that it still holds.
- Yuki_Code1 took the demo apart on trust framing and was right about who the warning was for.
Where it stands honestly: the agent already re-probes what it touched (curls the port, verifies the cert issued, checks the firewall rule sits ahead of the reject) and it isn't allowed to call something done off a bare exit code. The full "here's what changed and here's what I couldn't check" report that madmike and nicominetti described is designed but not built — it's next if people actually want the core.
Free trial, no card. Tell me where it breaks.
https://www.producthunt.com/products/server-manager?utm_source=other&utm_medium=social
"isn't allowed to call something done off a bare exit code" is the line that got me, that's the exact same principle from a thread earlier this week about AI checks reporting success while measuring nothing. a green light that didn't actually verify anything is worse than no check at all, because it actively trains people to trust something unverified
the re-probing detail (curls the port, verifies the cert issued, checks the firewall rule ordering) is doing the real work here, most tools would stop at "command executed successfully" and call it done. building something that shows the plan before acting too, phone commands instead of server ops, and the thing I keep relearning is that showing the plan is only half of it, verifying the actual outcome after is the harder, less glamorous half that's easy to skip
the unbuilt "here's what changed and here's what I couldn't check" report is the part I'd actually want most as a user, honestly more than the re-probing itself, since "I couldn't verify this" said honestly is more trustworthy than a silent assumption of success. any sense of timeline on that, or is it waiting on real usage data to know which gaps matter most first
The key point is that an exit code alone doesn't prove success. For operations work, I'd start the report with the exact probes that passed. Then I'd add a separate "not checked" section that a green status can't hide. The user can decide whether to accept that risk. They can't make a good call based on "deployment complete."
“Isn’t allowed to call something done off a bare exit code” is probably the most important sentence in the whole post. One refinement I’d make for the report you haven’t built yet: reprobing what you changed only proves that the change was applied. It doesn’t prove the property the user actually cares about. A cert being issued, for example, doesn’t mean it’s being served by the right vhost.
For an ops agent, the error costs are also asymmetric. A false “all clear” can be much more damaging than a false alarm, so that should directly shape what the agent is allowed to claim. The inverse list (explicitly showing what nobody checked) is probably the first feature I’d ship. Being upfront about the limits is what makes the rest of the report believable.
Good luck with the launch today.
Relate to the "wall after the AI finishes the app" framing, hit a version of it myself building a calorie tracker mostly through Claude. Sidestepped the raw-server side of it entirely by going with Supabase for the backend instead of a VPS, so no SSH/reverse-proxy/Docker layer to babysit, but that also means I've got no real feel for how hard this problem hits people who did go the raw-server route.
The "second deploy on a box you'd already declared done" point from madmike rings true from an adjacent place though: my worst App Store rejections weren't from the first submission, they were from confidently re-submitting a fix I was sure had shipped and finding out something else had quietly broken. The "say what you checked AND what you didn't check" instinct sounds right, that's basically what Apple's own reviewers force you into, a specific claim about what was actually verified, not just "should be fixed now."
The trust problem feels more interesting than the automation itself here.
Curious whether users are more concerned about what the agent can change, or about what it might miss while telling them everything is fine.