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
Manan, "a green light that didn't verify anything is worse than no check at all" is better than how I've been saying it, so I'm stealing it. That's the exact failure I built against: a check that comes back clean because it never looked is worse than nothing, because now the person stops looking too.
On your question — no date, and I'd rather tell you why than invent one.
It isn't blocked on design. I have the shape of the report written down: what changed, what I verified from your server, what I verified from outside, what I couldn't confirm, and what isn't my layer at all. Those last two lines are the ones I actually care about. "DNS resolves from where I'm standing, I can't tell you it's propagated everywhere yet" is a more useful sentence than any green check I could print.
What it's blocked on is that today every probe runs on the box, over SSH — and that's the wrong place to stand for about half of what goes wrong. A server's own firewall can be wide open while the cloud provider's security group quietly drops the port. The box tells you it's listening and it's telling the truth; it just can't see the thing that's blocking you. Same with DNS: the box has it cached, so it says fine while the rest of the world hasn't caught up. So v1 is doing the resolve through a public resolver, a TCP connect, and a real HTTPS fetch from our backend — a different network than the user's box — and only then writing the report. That's the actual work. It's weeks, not a quarter, because the checks already exist. They're just standing in the wrong spot.
The honest reason it isn't started: it's a differentiator, not the core. If people don't connect a server and let the agent do real work on it, the world's most honest verification report is a report about nothing. So yes, it's gated on usage — and the signal I'm watching is narrow: do people get through one real change on their own box without me in the room. If this week gives me that, this is what I build next.
One pushback on wanting the report more than the re-probing: I don't think you can have that trade. The report is only as honest as what's under it. Without the re-probe, "verified" is an exit code in a nicer font. The probing is what earns "couldn't confirm" the right to be believed.
What are you building? Approving server changes from a phone is a harder version of this problem — less room to show the plan, and the person is even less likely to be somewhere they can fix it if it goes sideways.
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."
Agreed on the exit code, and on keeping the two lists apart. Where I land slightly differently is the order — I'd put what changed first, then the probes. After an agent has touched your box the first question is "what did you do", not "what did you check". The probe list is the evidence for that claim; on its own it's floating.
The part that took me longest to get right: a probe line only counts if it's specific enough for you to tell me it's wrong. "Firewall configured ✓" is the same green light in a different font. "443 ACCEPT sits ahead of the reject rule" is a claim you can read and say no, you checked the wrong chain. Same with certs — not "HTTPS working" but issued, chain valid, and it's the domain you actually asked for.
On the not-checked section: the problem I had to solve there is that the list is infinite, so it's only useful if it's scoped to what a reasonable person would have assumed was covered by the thing I just did. And it wanted splitting in two, because the halves carry different weight. Couldn't confirm — I tried, it's inconclusive: DNS resolves from where I'm standing, I can't speak for the whole internet. Not my layer — your app's own auth and injection bugs: I'm never going to check that, and you shouldn't sit around waiting for me to.
That second line is the one people keep telling me is the reassuring part, which is not what I expected when I wrote it.
“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.
Agreed on the principle, and it's the rule the checks are already written to: the probe has to be the property, not the mechanism.
The cert case is the cleanest example of it. I don't check that issuance succeeded — that's the mechanism, and it tells you nothing about what a visitor gets. The check is a real curl -I https://<domain> against the hostname, which is the request that actually selects the vhost. If that doesn't come back 2xx/3xx it isn't done, and on the reverse-proxy migrations a failure there rolls the whole change back rather than filing a warning next to a green tick.
Firewalls are the same shape. If Docker is on the box the agent won't touch ufw at all — it works in raw iptables and preserves Docker's own chains, because a textbook-correct ufw rule on a Docker host is exactly your point: it applies cleanly and the property doesn't hold, since Docker writes its rules ahead of it.
The limit I'd put on my own claims is the vantage. Those requests still originate on the server. They exercise the real hostname and the real vhost, but they can't see a cloud security group sitting in front of the box, and they can't tell you DNS looks the same from anywhere else. So where that's the remaining unknown the agent says so and hands you the provider-side step instead of printing a check. Moving those probes somewhere that isn't the box is the first half of the report we're talking about — the half that turns "reachable from here" into "reachable for a stranger".
Your asymmetry point is the one that settles the wording: inconclusive degrades to "couldn't confirm" and never quietly to ✓, and a check that didn't run still has to appear. A missing line reads as green.
And you're right to put the inverse list first. Bonus reason: it needs no new infrastructure — it's derivable from what the agent already knows it didn't do. That's a week, not a build.
Thanks for the launch wish, and for being the second person to land on inverse-list-first independently. That's the signal.
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."
Supabase for a calorie tracker is the right call and I'd have made the same one. If a managed backend covers what you're building, there's no prize for running your own box.
Your App Store parallel is better than you're giving it credit for, and it named something I hadn't put words to. Apple hands you an external reviewer — someone who isn't you, isn't on your machine, looking from outside and willing to say no. Nobody does that for a server. You change something, it looks fine from where you're standing, and your only reviewer is whoever hits the site next: you at 2am, or a customer who just quietly leaves. The whole "what I checked and what I didn't" idea is really an attempt to be that reviewer — and specifically one that admits when it couldn't see something instead of stamping approved.
"Confidently re-submitting a fix I was sure had shipped" is the exact failure, too. It's not hard because the state is complicated. It's hard because what you actually need is a diff — what moved since it worked — and looking at the thing fresh can only ever tell you what's true right now.
Genuine question, since you're on the other side of it: does Supabase spare you the second-deploy problem or just relocate it? RLS policies and env vars on a project you'd already declared done seem like they'd carry the same "I was sure that shipped" feeling.
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.
My read is that they aren't competing — they're sequential.
"What can it change" is the loud one, and it's the fear people have before they've used it. It also resolves inside a single interaction: you ask for something, you see the literal command before it runs, and nothing happens until you say go. For the irreversible ones it tells you in plain English what you'd lose, so answering that fear doesn't require you to be able to read shell.
"What might it miss while telling me it's fine" is the one that survives that, and it's harder for a structural reason: it has no moment. A change you didn't want announces itself. A check nobody ran feels exactly like everything being fine — there's no notification for an absence. Which is why the interesting design question isn't how confidently to say done, it's how to make what wasn't checked as visible as what was.
Worth saying the numbers behind that are small — it's from conversations and threads like this one, not a dataset. If you've built anything agentic, I'd like to know which way it went for your users. I'd have guessed the first fear dominates, and it doesn't seem to for long.