Building in public: a chat assistant that runs your server so you don't have to live in the terminal

This is exactly the right thing to be strict about, and it's the part of the design I've spent the most time on. Direct answer to your question: you read the literal command.

And it's the literal command for a structural reason, not because I'm promising to be careful. The approval card is generated by the actual command the agent is about to run — the Approve button is wired to that command, not to the sentence describing it. So it can't call an rm -rf "tidying up" and then run the rm -rf, because the thing you approve is the command itself, sitting right there to read. The plain-English line rides on top for when you don't feel like parsing flags, but it's a convenience layer, never the source of truth.

Your "clear out the old logs" example is the real case, because you're right that the intent maps to several commands and one of them ruins your afternoon. What the card does is collapse that ambiguity back to the one concrete command it picked, so you inspect the actual rm / find -delete / truncate before it runs and kill it if it chose wrong. For anything destructive it also shows what it's about to touch and flags when the action isn't reversible, because the confirmation is gated on irreversibility, not on "is it technically a write." Reversible stuff shouldn't nag you; one-way stuff should stop you and show its work.

Rather than take my word for it, here's a short walkthrough of Faro actually running a server — you can watch it propose each action and wait for the approve step in the real product: Let Faro Run Your Server.

This is the sharpest "worst part" answer anyone's given me, and it reframes the whole thing. The one-time cliff you push through and it's done — you're right. What taxes you forever is the layer you named: config that's invisible until it shifts, then lies about where it broke.

This is squarely what Faro is built to attack. When something's off, its whole reflex is to check the boring infrastructure first — is the container actually running, is the proxy routing, is the cert live, is the firewall in the way — and tell you which layer broke in plain English before you've opened a single log. The value isn't any one check; it's that it won't let you burn the afternoon reading the innocent layer. That "the error is code-shaped but the cause is infra-shaped" gap you hit is the exact one it's designed to close.

Your webhook is the honest edge of that: the service was still up, so those infra checks would've come back green — the culprit was a value, not a down component. That's the layer I want to take the same reflex into next: past "is it running" to "does the config the running service actually booted with match what's on disk and what you think you set." Same instinct, check the unglamorous stuff first, one level deeper — into the exact drift that ate your week.

So a real question, since you've lived it: would you have wanted an always-on watcher that flagged the drift on its own, or just the agent's first move being that config diff the moment you said "the webhook's failing"? I go back and forth on whether the value's in the watching or in always checking config first when something breaks.

On distribution — no fake advice, we're in the same boat for real. I'll keep posting whatever actually moves the needle, so steal all of it, and I'll be reading yours for the same reason. Following back.

Yeah, this is the part I care most about, so let me answer it precisely.

Short version: it shows you the plan before it runs, for exactly the class of thing you named. Faro proposes the action as a card with the actual command it's about to run plus a plain-English explanation of what it does, and nothing in that category executes until you approve it. Firewall changes and cert swaps are both in it.

The part I've thought about most is where to draw that line, because the real failure mode isn't only "agent does something destructive," it's approval fatigue. Make someone confirm every single step and they stop reading and start rubber-stamping, and at that point the gate is just theater. So the threshold isn't "is this a write," it's "how recoverable is this if it's wrong." Read-only diagnosis just runs. Easily reversible changes mostly just run. What gets gated is the stuff that's genuinely hard to walk back: opening a port, swapping a cert, deleting files, anything with real blast radius. That's where you see the plan first.

The thing I'm deliberately careful not to do is promise a magic undo for actions that can't actually be undone. Some things are one-way, and the honest move there is to show exactly what's about to happen and let you say no, not to pretend it rolls back cleanly afterward.

When it shows you the plan, would you rather see the literal command it's about to run, or a plain-English summary of it? One risks scaring non-technical people, the other risks hiding what's actually happening, and that default is the thing I keep flip-flopping on.

This is the sharpest version of it I've seen, thanks. And funnily enough I've been on the receiving end of the wrong version this week, someone answered a couple of my questions then slid into a cold pitch, and yeah, the ick was instant. So the ordering you're describing isn't just about being polite, it's the difference between the whole thing working or not.

The "let the public answer do the work" part is basically the bet I'm running right now, mostly on Reddit: answering people's actual server problems in the open with the maker thing disclosed, and letting whoever wants more raise their hand. What you added that I didn't have is the closing line. "Happy to show what I'd do on a blank VPS" is a much better shape than anything I'd landed on, because it's still help, not a demo request in disguise.

The one bit I keep turning over: when you're also the person who built the tool, does that low-pressure offer stay clean, or does the disclosure quietly turn it into a soft pitch no matter how you word it? Curious how you'd keep that honest, since you clearly think about the ick line carefully.

Exactly, and I think the "part-time" is the whole trap. Because you only touch this stuff every few months, you never build fluency — so every time a cert quietly expires or a proxy starts 502ing, you're back to square one, re-reading the same docs you read last time. The work itself usually isn't hard; it's that it's infrequent, a little scary, and sitting right between you and the thing you actually wanted to run. That gap is exactly what I'm trying to close: describe the outcome, skip the re-derivation.

Did you cross over and make peace with the sysadmin side, or are you still in the "why am I doing this again" camp?

I love this question, and this idea - it lands right where MCPs get really interesting for me. It serves a space where, "I know what I want to do at a high level, but I lack the low-level expertise to make it happen."

For my two cents though, I'd absolutely use this as a solo founder/developer. Unfortunately, I still have a day job., so my time is limited, and I want to spend it building, not doing sysadmin work. It's not that I can't or don't know how - it's just that it's a chore I'd rather minimize my time/effort on.

Good question, and I'll pick rather than hedge: the primary wedge is reducing sysadmin complexity for people who aren't sysadmins — the same person from my other reply, who bought the box and can build the app but freezes at the reverse proxy.

What convinces me is where the acute pain actually sits. In every thread I've been in, the person about to give up is never the experienced dev shaving time off a workflow — it's the newcomer who hit the wall. "Make experienced devs faster" is a hard wedge because they've already crossed that wall: they've got their own scripts and muscle memory, so a tool saves them a few minutes at most. The newcomer who'd otherwise quit or overpay for managed hosting gets a completely different order of value — crossing a wall they couldn't get over at all. That asymmetry is the whole argument.

What would flip me: if usage data showed the opposite — CLI-comfortable power users running multi-server setups coming back daily while first-timers bounced after one task. That's the falsifiable version. So far everything about the product (the propose-then-confirm approval step, the plain-English explanations, "why is my site down" as a first-class command) is built for the person who doesn't want to become a sysadmin, and that's who leans in.

Experienced users do get value and I'll happily take them, but as an expansion segment, not the wedge. Trying to be the tool for both from day one is how you resonate with neither.

This is a genuinely useful reframe, thank you — and yes, that's exactly the play I'm running right now: being useful in those threads (r/selfhosted, the VPS subs) with zero pitch, and only mentioning the product when it's literally the answer to a direct "is there a tool for this?". Slow, but the conversations are real, which beats shouting into a launch.

One refinement I'd add to your "selling to people who already bought their solution" point, because it's the thing I keep bumping into: the coldest prospect is someone comfortable on managed hosting — they have no pain. The warmest is the person who deliberately bought a raw VPS (Hetzner, Contabo, Oracle's free tier) precisely because they wanted to own the box, and then hit the sysadmin wall. They've already self-selected for ownership and they're actively stuck — motivation and pain in the same person.

The subtlety with r/selfhosted specifically is that a lot of it skews greybeard — people who conquered that wall years ago and half-enjoy the config. The pain lives one notch down from them: the semi-technical newcomer who can build the app but freezes at "SSH in and edit the Caddyfile." So the community's right, I just have to aim at the person asking the beginner question, not the person answering it.

On the "reach out directly" part — my hesitation there isn't nerve, it's that a cold DM to someone mid-problem tends to read as "I was watching you struggle so I could sell you something," which torches the exact trust that being useful in the open is meant to build. So I've bet on being the most helpful answer in public and letting people come to me. Have you seen direct outreach actually convert without that ick, or does patient-and-public just win on a longer clock?