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
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.