A chat assistant that runs your server so you don't have to live in the terminal
Hello everyone,
I'm Igor. I've spent a long while heads-down building Server Manager, and I'm now flipping from building to actually putting it in front of people — so I want to do the rest in public and learn from this crowd.
The problem I kept seeing: loads of people buy a server (Hetzner, Contabo, a DigitalOcean droplet, Oracle's free tier…) to self-host something — WordPress, a database, a small app, Vaultwarden — and then hit a wall. Not the "install the app" wall. The sysadmin wall: SSH, a reverse proxy, HTTPS certs, DNS, firewalls, Docker. Semi-technical folks get stuck there and give up, or overpay for managed hosting.
What I built: you connect your server, then just tell an agent (Faro) what you want — "deploy WordPress and put it on my domain," "back this up," "why is my site down" — and it does the sysadmin part, explaining each step and asking before anything risky.
It's live at https://servermanager.dev if you want to poke around (free to try, no card).
Honest traction: basically pre-traction. A handful of signups, one paying user, a trickle of traffic converting to roughly nobody. I've been so deep in the product I've done ~zero marketing. That changes now — which is exactly why I'm here.
Two bets I'm making:
- Talk to your server, don't configure it. Describe the outcome, not the config — the agent does the sysadmin work.
- You own the box. Not another PaaS you rent — your server, your data, your provider; the app is just the layer that makes it manageable.
I'll post the journey here — what works, what flops, the numbers. Two things I'd love from you:
- If you've self-hosted on a server and hit that wall (or powered through it on purpose), what was the worst part?
- If you've launched a dev-adjacent tool: how did you get your first 100 real users?
Thanks in advance for any feedback and suggestions
You're right and I think I had the causality backwards. I was treating the refusal as the proof, but the refusal is downstream — it only means anything if the gate already happened, and the gate is the part that answers the actual fear. Nobody's asking whether no works. They're asking whether the thing waits.
The half-teaching point is the one I'll keep. Dwelling on "nothing bad happened because I declined" plants the idea that something bad was available, which is exactly the frame you're trying not to hand a first-time viewer. Show the stop, not the near-miss.
So the throwaway box shot is: it proposes, it stops on its own, the literal command sits there with the irreversible flag on it. End there. The visitor fills in the rest themselves, and what they fill in is "it waited."
Followed you back. Good luck with the launch — I'll be watching for the reel.
That's the whole thing, and you framed it better than I did: end on the stop, and "it waited" is the line the viewer writes for themselves. That's the cut worth shooting — it proposes, stops on its own, the command sits there with the irreversible flag, end. Thanks for grinding this all the way down with me; it genuinely sharpened how we'll show it. Followed you back, glad to have you watching, and I'll make the reel earn it.
I'll take the first question — the worst part of self-hosting for me wasn't any single step, it's that I run a distributed system (several services, a database, a queue) and the wall isn't the initial setup, it's the second deploy. The first time you change something on a box that's already "done" — a cert that quietly expired, a firewall rule from last month that now blocks the new service, a proxy config still routing to the old port — that's where I lose the afternoon. And the error almost never points at the actual cause: it says "connection refused" and sends you debugging the app while the truth is a DNS record that never propagated.
The describe-the-outcome bet is the right one. But the part I'd want most from an agent isn't help running a command, it's a verification pass after the fact — not just "done," but "here's what changed and here's how I checked it holds": cert live from outside, port answering, proxy actually routing. The propose-and-approve card handles the risk side; the part I'd trust first is knowing the action didn't just run, it stuck. Curious if that's on your roadmap or if you see verification as out of scope.
The second deploy is exactly the right place to point. First setup at least has your full attention — the killer is touching a box that's been quietly "done" for months, where the thing you change collides with a decision you don't remember making. And the error lies about the layer almost every time:
connection refusedsends you into the app when the truth is a proxy still routing to the old port or an A record that never propagated. That misdirection is most of the lost afternoon.So to answer directly: verification isn't out of scope, it's already how the agent runs. After it changes something it re-probes the thing it touched — curls the port to confirm it's answering, checks the cert actually issued, confirms the new firewall rule landed in front of the reject, checks the domain resolves to the box's real IP and stops cold if it doesn't. And there's a hard rule underneath: it can't say Done just because a command exited 0 — if a check comes back unexpected it has to narrate what changed before it can claim success. Done is meant to mean verified-with-evidence, not "the command ran."
Where you've named the real gap is the word outside. Almost all of that runs from the box itself over SSH — which catches the cert answering, the port bound, the A record pointing right, but it isn't a check from off your network. A true external vantage — cert valid to a stranger, DNS actually propagated past your own resolver, port answering from the public internet — is the piece I'd make a first-class post-action pass instead of something it does implicitly. And oddly, someone else in this thread asked for the mirror image of it (after a scan: "here's what I looked at, and what nobody did") — yours is the same artifact pointed forward: "here's what changed, and here's how I confirmed it held." That's the version I want too.
The worst part of self-hosting for me was always the reverse proxy + SSL cert dance. Every time I set up a new service on a VPS I'd lose an hour to nginx configs and certbot renewal issues. If your agent handles that reliably in one command, that alone is worth the product.
For first 100 users in dev-adjacent tools — what worked for us wasn't any platform in particular, it was specificity. Generic "deploy anything" messaging gets ignored. But "deploy WordPress on Hetzner without touching SSH" — that stops someone mid-scroll because it describes their exact situation.
I'd go deep on the self-hosting subreddits (r/selfhosted, r/homelab) and answer questions people are already asking about nginx/certbot/docker setup. Don't pitch the product, just solve their problem and mention you built something that automates it. That's where your first 100 users are hanging out right now.
Yeah, the reverse proxy + cert renewal dance is exactly the thing I built this around. It's the part where people either give up or end up with a broken auto-renew they don't notice until the cert's already expired. The agent stands up Caddy and gets HTTPS going in one shot, and since Caddy handles renewal itself there's no certbot cron sitting there waiting to rot. You just tell it what you want in plain English and it does the SSH and config work.
The specificity point really lands. "Deploy anything" is noise, everyone says it and nobody believes it. What stops the scroll is the exact situation someone's already in. That's the direction I've been pushing the positioning: instead of fighting the crowded "easy deploys" pitch, the wedge is the scary layer underneath (the SSH, the proxy, the HTTPS, the firewall) made safe for people who'd rather not live in the terminal.
On the subreddits you're dead right, that's where they are, and I've been spending time in r/selfhosted. One thing I picked up the hard way: that crowd can smell a pitch from a mile off, and a lot of them are proud of their hand-tuned nginx. So the move isn't "here's my tool," it's actually answering the certbot question someone posted and only mentioning what I built when it genuinely fits. Slower, but the people who come in that way tend to be the ones who stick around.
Appreciate you writing this out.
I'm close to your target user: product/UX person, shipped a SaaS to production by directing AI, still can't write a function from scratch. The terminal was never the hard part for me. The hard part was not knowing what I didn't know — I could run the command, I just couldn't tell whether the result was right.
Which is why I'd push on the destructive-commands thread above. Showing me the command before running it doesn't help someone like me: I can't evaluate the command. Showing me what I'd lose does. "This removes the database and its backups" is something I can say no to.
On distribution — I'd be careful with r/selfhosted and VPS forums. The people there mostly don't need you; they enjoy this stuff. The ones who need you are in the AI-builder and no-code communities, where people ship an app and then hit a wall the first time something has to actually run somewhere.
You might be the most precise description of the target I've gotten. And you're right that it was never the terminal, it's whether you can trust the result. That's the actual wall, and it's the whole reason this thing exists.
On the destructive thread: you and Yuki_Code1, who wanted to read the literal command, aren't opposite answers, you're the two halves of the same card. They wanted the command because prose can dress up an rm -rf as "tidying up." You need "this deletes the database and its backups" because the command itself is noise to you. So the card gives both, the exact command for people who read commands, and the plain "here's what you'd lose, and it's not coming back" for people who decide on consequences. For you that consequence line is the whole point: you don't have to evaluate the command, you just have to know what's at stake, and that's the line you say no to. No proficiency required, by design.
On distribution, this is the sharpest thing anyone's said to me, and it matches what I'm already seeing. The r/selfhosted crowd mostly enjoys the fiddling; they're not who this is for. The person who shipped a SaaS by directing AI and then hits "wait, it has to actually run on a server somewhere" is exactly it. I hang around the self-hosting subs to learn the failure modes and be useful, not because I expect them to convert. So a genuine question, since you live in those communities and you are the user: where does that wall actually show up for people? Which no-code / AI-builder spaces, and what's the moment they realize they're stuck, is it deploy, is it "it works locally but not live," is it the first time something breaks at 2am?
The wall for me wasn't really infra ops — it showed up earlier, around security. Once I had something live with real user data behind a login, "the AI wrote code that works" stopped being enough. I had to actually go learn what OWASP Top 10 is and what a zero-day even means, not to become a security engineer, just enough to know what I was supposed to be defending against. Did that homework in dev, before anything touched production — so whatever I would've gotten wrong got caught there instead of turning into a real incident with real users' data on the line.
That's maybe a second version of "the wall" worth thinking about for your wedge: it's not only "can I get this running on a server," it's "do I actually know if what's running is safe." For someone at my level, those feel like the same wall from the outside — you don't know which one you're about to hit until you're already stuck. Is that something Server Manager thinks about at all, or is the scope staying deliberately on the ops side (proxies, certs, deploys) and leaving security posture to a different tool?
Security posture is in scope, and honestly it's closer to the center of this than the ops plumbing is. Certs and proxies are the part people notice, but what's actually exposed, which ports are open, whether SSH is locked down, whether something's listening on the public internet that shouldn't be, that's the same "do I know this is safe" wall you're describing, just at the server layer. So yes, it looks at that and does something about it.
Where I stop is your app's own code. The OWASP homework you did, the injection and auth bugs in logic the AI wrote, that's a different discipline and I'm not going to pretend a server tool audits your source. You're right that from the outside the two walls look like one, you don't know which you're hitting until you're stuck. Server Manager takes the one it can actually own, the server and everything exposed on it, and leaves the code to something built for code.
Drawing that line out loud is worth more than you probably think. When you don't write the code yourself, the failure mode isn't picking the wrong tool for the layer — it's not knowing the layer exists. A tool that says "the server is mine, your source isn't" at least tells me there's a second thing to go find. Tools that stay vague about scope let me believe I'm covered.
Which makes me think the most useful thing you could ship isn't another check — it's the inverse list. After a scan: here's what I looked at, and here's what nobody looked at. The second half is the part I'd screenshot.
Taking the port/SSH/exposure layer and stopping there is the right call. The seam between the two is where people like me get hurt, but it's not yours to close.
The inverse list is the part I'm keeping. I'd been treating the scope line as an honesty tax — the thing I have to admit a server tool can't do — and you've flipped it into the most useful thing it can output: not "here's what I checked," but "here's what I checked, and here's the layer nobody did." For someone who doesn't know the layers exist, that second half is the whole point, and you're right that it's the screenshot.
That one's going in the notebook as a real feature, not a nicety — naming the seam you can't close is how you stop a green checkmark from reading as "safe."
The appeal is obvious for anyone who maintains a box they don't touch often enough to stay fluent in. The thing I'd want nailed down before pointing it at anything real is the destructive path.
Natural language is ambiguous in exactly the places a shell isn't. "Clear out the old logs" has an obvious intent and several possible commands behind it, and one of them ruins your afternoon. Is there a confirmation step that shows the literal command before it runs, or does it explain in prose what it's about to do? I'd much rather read the command — prose can describe a rm -rf as tidying up and be technically correct.
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.
"The Approve button is wired to that command, not to the sentence describing it" is the sentence that settles it. That's a structural guarantee rather than a promise about care, and those are the only kind worth trusting in a destructive path — the prose can be wrong and it still can't hurt me, because the prose was never what I approved.
Gating on irreversibility rather than on write-vs-read is the other decision I'd have gotten wrong. Nagging on every write trains people to click through, and then the confirmation is worthless exactly when it matters. Reserving the interruption for one-way actions keeps it meaningful.
I'll take a look at the walkthrough. Thanks for answering the specific version of the question rather than the reassuring version of it — that's most of what I'd want to know before pointing something like this at a real box.
That's the whole bet: a structural guarantee holds where "I'll be careful" doesn't, and the destructive path is exactly where you want it. You put the irreversibility point better than I usually do, too — nag on every write and you've trained people to stop reading the box by the time it matters. If you point it at something after the walkthrough, I'd genuinely want your read on where it still feels ambiguous; the instinct to reach for the literal command is usually what finds the edge I haven't.
Looked at the Server Manager section. The thing that struck me isn't ambiguity in a card — it's that the demo doesn't show one.
"Deploy WordPress on a new subdomain" runs through provisioning, TLS, firewall, DNS, and every line resolves to done. Which is honest for that request, since none of those steps are irreversible and by your own rule reversible things shouldn't nag. But the effect is that the visitor never sees the mechanism you've spent the most design time on. They see an agent that does things, which is exactly the thing a careful person is nervous about.
If it were mine I'd want one destructive request in that reel — the "clear out the old logs" case — so the approval card gets a moment on screen with the literal find -delete sitting in it and the irreversible flag showing. Right now the strongest argument for trusting Faro is in your comment here and not in the demo.
Where I'd actually expect ambiguity, if I'm reading the flow right: the plain-English request names a scope, not a command. A new subdomain, the old logs, the unused containers. The card collapses that to one concrete command, which is the right move — but the thing I'd double-check as a user isn't the verb, it's the set. find -delete is unambiguous about what it does and entirely dependent on the path and the age threshold sitting next to it. Are those always in the card verbatim, or does anything get elided for readability when the command runs long?
Fair — and I think the reel's doing the job it's actually for. It's the thirty-second "here's the shape of the thing" for someone who hasn't decided to care yet, and for that viewer a red "this can't be undone" flash mid-reel does the opposite of what it does for you: it foregrounds danger to a person whose only question so far is whether this is going to be a pain. So the card sits one layer in on purpose, not because it's tucked away.
Where it actually lives: the walkthrough shows Faro proposing every action and waiting on the approve step in the real product, and the "will this break my server" piece writes the rule down plainly: read-only runs on its own, anything that writes or deletes or restarts stops for you, and the irreversible ones warn and ask twice. More of the same at /help and /help/videos.
I'll be straight about the limit of all that, though: every polished flow I can point you to is a reversible one — install WordPress, attach a domain — so it shows the approve card but not the irreversible flag, for the same reason the reel doesn't. The only thing that really shows you the flag is making the product show it to you. Which is the version I'd trust if I were in your seat anyway: spin up a throwaway box, point it at nothing you'd miss, ask it to clear out the old logs, and watch the card render the literal
find -deletewith the not-reversible warning sitting on it. That's the free trial. Same move you've made the whole thread — don't trust the prose, read the command — just one turn further: don't trust the reel, or me. Make it show you.And if the flag reads ambiguous when you do, that's the note I actually want back.
The audience split is a fair read and I hadn't weighted it properly — a thirty-second reel is for someone who doesn't yet know they should be nervous, and leading with a warning teaches them to be nervous about your product specifically rather than about the category.
But I'd push back slightly on where that leaves the throwaway box. The reversible backup example is fine and it isn't the thing that would convince me, because a product that takes a backup before upgrading WordPress is just a competent product. The find -delete card is the thing nothing else in the category has, and burying it means the visitor's mental model of Faro is "agent that does stuff" — which is the model they already had, and the one that makes them hesitate.
The way I'd square it: don't put it in the thirty seconds, but make it one click away and label it honestly. "What happens when it's about to do something irreversible" is a link a cautious person will absolutely follow, and the cautious person is the one who ends up pointing it at a real box.
If you do shoot it, I'd want to see the moment you decline. Approving is the boring half — the interesting frame is the one where you read the command, say no, and nothing happened.
Also, I'm on X as @ark_y_k if you're there. Easier than chasing threads.
You've moved me on the main point, and on the part I'd gotten wrong: the backup-before-upgrade example is table stakes — any competent tool does that — so leading with it proves nothing. The
find -deletecard is the one thing the category doesn't have, and you're right that hiding it leaves the visitor with the "agent that does stuff" model that makes them hesitate in the first place. Burying the only real differentiator to avoid scaring people is a bad trade when the differentiator is the reassurance.So your resolution is the shape I was missing: not in the thirty seconds, but one click away and honestly labeled. "What happens when it's about to do something irreversible" is a link the cautious person follows on purpose — and the cautious person is the one who ends up pointing it at a real box, so that's who it should be built for. It threads the needle I was stuck on: it doesn't teach the casual viewer to be nervous, and it hands the careful one the thing they came to find.
Where I'd push back is the decline shot. I don't think "you say no and nothing happens" is the frame that earns trust — it answers a question nobody's really asking. Nobody's afraid a command they didn't approve will run; everyone knows an unclicked button does nothing. The nervousness around the word "agent" isn't "is declining safe," it's "does this thing even wait for me, or is it off doing things on its own?" So the shot that matters isn't the refusal — it's the gate: the agent stopping on its own and putting the literal command in front of you before it touches anything. Proof that it always asks beats proof that no means no. And dwelling on "nothing bad happened when I declined" half-teaches the viewer that something bad could have — which is the fear I'd rather not hand them in the first place.
Yes to X — just followed you, I'm @servermanagerD. Easier than both of us watching for the red dot here, and I'd rather keep this going somewhere you don't have to dig for it.
The gate reframe is better than what I gave you, and I think it's because you named the actual fear correctly. I was answering "can I stop it," which is a question about control. You're answering "is it already running," which is a question about whether the thing has a leash at all. Those feel similar and they aren't — the second one is what makes someone close the tab, and no amount of demonstrating a working decline button touches it.
The half-teaching point is the one I'll take with me. I've been assuming that showing a failure being caught proves the catching works. It also proves there was something to catch, and if the viewer hadn't considered that yet, you just introduced it. That's a real cost and I hadn't priced it.
So the shot is the agent stopping unprompted with the literal command sitting there unexecuted — no user input in the frame, which is what makes it read as the product's behavior rather than the user's vigilance. That's a harder thing to stage honestly than a refusal, since you have to actually let it get that far.
Followed you back — @ark_y_k. I'm launching something on PH next week, my first, so I'll likely be asking you things about how the demo landed rather than the other way round.
The gate frame doesn't stand without your decline idea in front of it — I only found the right shot because you set the wrong one where I could look at it, and "wrong first, then the real one" is pretty much how the whole reel got built. So keep the runway; it's yours.
What I keep circling back to is your last line: you have to actually let it get that far. That's the part that keeps the shot honest whether I want it to or not. A refusal costs nothing to stage — I can invent any command and just not click it. The gate can't be faked the same way. To film the agent stopping at a real irreversible boundary I have to build a scenario where it genuinely would delete something, point it at a box I'm willing to lose, and trust it to stop on its own. If it stops, I filmed the truth. If it doesn't, I don't have a demo, I have a bug. So the difficulty you named is the demo's own integrity check: the shot only exists when the behavior is real, which means the day I catch myself staging it to look better than it is, that's my answer that it isn't ready to show. Real throwaway box, a real
find -deleteactually pending, hands off the keyboard, let it run all the way to the gate — whatever ends up in the frame is what the product did.Happy to be on the other end of the questions, though I'd drop the "rather than the other way round." Send me the demo before you go live and I'll tell you exactly where my eye slid off it; I'll be doing the same to you the week I go. Good luck with the first one — that's a good kind of nervous. I'll be watching for it.
On "what was the worst part" — for me it wasn't any single command, it was the invisible config layer that bites you long after setup, with an error that points at the wrong thing.
Concrete example from last week: a payment webhook kept failing signature verification. Everything in my code looked perfect, so I burned real time debugging the code — when the actual cause was a single wrong secret value sitting in my host's env vars. The error screamed "signature invalid" (a code-shaped problem) when the truth was "one string in your config is wrong" (an infra problem). Nothing in the stack connected those two.
That's the wall I'd want Faro to help with, honestly — not the initial SSH/cert setup (that's a one-time cliff you can push through), but the ongoing "something outside the app changed and now nothing lines up" state. If the agent could flag "heads up, this env var/secret doesn't match what the running service expects" before I lose an afternoon to it, that's worth more to me than the deploy step.
On your first-100-users question — no advice, I'm in the same boat right now, honestly trying to figure out distribution myself. Following to steal whatever works for you.
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.
Honestly, for the exact bug I hit, the always-on watcher would've been blind — and that's what tips me toward "config-first the moment I report it."
Here's why: a watcher detects drift, a delta from some known-good baseline. But my secret was wrong from the very first deploy — it never had a good state to drift from. Nothing changed the day it "broke"; it was broken the whole time and I just hadn't hit that code path yet. A watcher looking for "what changed" sees nothing, because nothing did.
The on-demand reflex covers both cases: when I say "the webhook's failing," having the agent's first move be "let me check the config the service actually booted with against what you think you set" catches the value that drifted AND the value that was never right. The watcher only catches the first kind.
The other thing pushing me the same way — always-on watchers earn alert fatigue fast. Three false "heads up"s and I mentally mute it, so by the time it's actually right, I'm not reading it. The config-first check fires exactly when I'm already paying full attention, because I'm the one who just said something broke.
So if you can only build one first, I'd build the on-demand config diff. The watcher is a great v2 once there's a real baseline to diff against — but the moment of value is the moment of pain, and that's when I want it checking the unglamorous stuff first.
(And yeah, following back — I'll steal your distribution wins shamelessly. Same boat, might as well row together.)
The "never had a good state to drift from" point is the one that lands hardest — a watcher is blind by definition to config that was wrong from birth, and those are the exact bugs that cost you an afternoon, because you trust the code and go hunting there. You've talked me out of the watcher as v1: config diff first, the watcher as v2 once there's a baseline worth diffing. Appreciate you reasoning it from the actual scar rather than a feature request. (Rowing.)
Ha — reasoning from the scar might be all I've got right now, so I'm glad it was useful for once.
Whenever Faro ships that config diff, point me at it — I've got a fresh supply of dumb secrets waiting to be caught. Rowing on.
Likewise — good luck out there. I'll be reading yours too.
The describe outcomes, not configure systems framing is the right instinct, most people who get stuck at the SSH, DNS, cert layer don't want to learn it, they want it done. My question as someone who thinks a lot about how much to trust an agent with real side effects, when Faro is about to do something destructive like a firewall change or a cert swap, does it show you the plan before it runs, or does it just execute and report back? That boundary is usually where semi-technical users get burned, not the initial setup.
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.
i think cold DMs only work after a public interaction, or when they literally asked for help. otherwise it gets the ick fast. let the public answer do the work, then leave a low-pressure ‘happy to show what i’d do on a blank VPS’ line. the people who raise their hand are the lead; everyone else just got a useful answer.
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.
Most people don't actually hate self-hosting, they just hate playing part-time sysadmin to fix broken reverse proxies and SSL certificates, so putting a chat layer over raw SSH is a massive lifesaver.
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?
The interesting positioning choice is between making server management accessible to non-technical users and making experienced developers faster.
What would convince you that the primary wedge is reducing sysadmin complexity for new self-hosters rather than improving workflows for existing server users?
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.
This is the exact distinction I've been trying to get right, thanks for putting it so cleanly. Most of the positioning talk in this thread has been about the person who can't cross the sysadmin wall, but you're describing someone who can and just doesn't want to burn scarce building time on it. Those feel like different people, but they want the identical thing: describe the outcome, don't do the config. The newcomer's version is "I couldn't get over this wall," yours is "getting over it is a tax on the work I actually care about." Same bet, different reason for taking it, and honestly yours might be the more durable one, because that opportunity cost never goes away even as you level up.
Since you said you'd use it, genuine offer and not a pitch: if you do spin it up on a blank box, I'd really like to hear where it actually saves you the chore and where it gets in your way. You're exactly the person whose "this was still annoying" is worth its weight to me right now. And if you hit anything, I'm around.
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.
Appreciate the detailed context.
Would be good to continue the conversation as you learn which segment shows the strongest pull.
What's the best email to reach you on?
Yeah, I'd like that. Easiest is probably X — @servermanagerD — or LinkedIn; connect there and you'll catch the updates as I post what the pull data actually shows, segment by segment. If email's easier, [email protected] reaches me directly.
Out of curiosity, what's pulling you toward the positioning angle — are you building in a similar space, or coming at it more from the go-to-market side?
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Thanks Aryan, and thanks for the genuinely thoughtful read — you've pegged the core decision exactly. My plan for now is to keep wrestling it in the open and let real usage do the arguing as more people try it, then post the twists here as they come. Appreciate you following along.
Hi Igor,
Thanks for the thoughtful reply.
That makes sense. Letting real usage reveal how people naturally understand and use ServerManager is a reasonable next step.
I’ll be interested to see what patterns emerge as more users try it and how the positioning question evolves.
Appreciate you sharing the journey publicly, and I’ll keep following along.
Thanks Aryan. That's the plan exactly, I'll post the twists here as the usage picture sharpens, so you'll catch them just by following along. Appreciate you engaging with it this seriously.
The sysadmin pain point is real - you've nailed the exact moment people give up. For your first 100 users question: dev tool distribution is brutal because you're not selling to individuals, you're selling to people who already bought their solution (managed hosting). Your warm channel is probably existing self-hosters who already have the pain. Communities like r/selfhosted, WireGuard forums, or Hetzner's own forums know exactly who you're building for. Have you tried reaching out directly to people asking about this specific workflow on those platforms?
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?