The realistic situation
You ship features, talk to users, do support, fix bills, and try to sleep. Somewhere on the side, you have one to three VPSes running your product. You set up the firewall and disabled root SSH on day one and have not opened the security tab in your panel since.
The standard advice is "hire a security engineer", "set up a SIEM", "rotate keys quarterly". You are not going to do any of that. The question is: what is the smallest thing you can install that meaningfully changes the outcome if someone targets you?
What solo founders actually need
Five things, in order of how often they fail in real founder setups:
One: alerts on your phone, not in a dashboard you will never open. Two: zero false-positive paging at 3 AM, or you will mute it within a week. Three: a dry-run mode so you do not get locked out of your own server because some hardening flag was too aggressive. Four: a single binary you do not have to think about, no agent fleet, no broker, no log forwarder, no Kibana. Five: autonomous response on the obvious stuff, because by the time the alert reaches your phone the attacker has been on the box for nine seconds already.
Inner Warden was built around exactly this constraint. The whole pitch only works if it stays quiet most of the time.
The "set it and walk away" install
One command, no DNS to configure, no account to create, no license server to ping.
curl -fsSL https://www.innerwarden.com/install | sudo bashThe defaults assume you are a human running a small fleet, not a SOC analyst. Detectors that have a long history of false positives in the wild are off by default. Detectors with high specificity, like SSH brute force on a non-standard port or/etc/passwdmodification by a non-package process, are on.
Why the AI confidence gate matters here
Most agent-based security tools either notify on everything (mute within a week) or autonomously block based on rules (great until they brick your own deployment script). Inner Warden runs detected events through a local AI triage layer first.
The triage layer is a small local model running on your box, no data leaves the host. It looks at the event in context: which user, which process tree, which time of day, which historical baseline for this host. It outputs a confidence number between 0 and 1. The default policy is: confidence above 0.85 plus a high-severity detector triggers an autonomous block. Confidence between 0.5 and 0.85 sends a Telegram message and waits for you. Below that, it logs and moves on.
In practice this means the autonomous blocks are the ones you would have approved anyway, and the alerts that wake you up are the genuinely ambiguous ones. False positives are a feature problem goes deeper on the model side.
The dry-run habit that has saved every founder I know
Every command that changes system state has a--dry-runflag. Every detector has a--notify-onlymode that runs the detection logic and shows you what it would have done, without acting. Run it for a week, read the messages, then flip--auto-blockon the ones that look right.
sudo innerwarden harden --dry-run
sudo innerwarden detector list --status
sudo innerwarden detector enable ssh_brute_force --notify-onlyThe most common reason a founder uninstalls a security tool is because it locked them out once. The dry-run path makes that almost impossible if you use it.
Telegram, not email, not Slack
Email goes to a folder you check at 11 AM. Slack goes to a workspace you might not check on Sundays. Telegram, for most founders, is the channel that lives on the lock screen. Setmin_severity = "high"and you will get one or two messages a month on a quiet box, more during a real incident.
Each message includes a one-line summary, the confidence score, and a deep link into the local dashboard. You can usually decide in 20 seconds whether it is a real thing.
What changes when something does happen
The hardest moment in a founder's security life is the first real incident: a Telegram ping at 11 PM about an unusual outbound connection from your API box. Without context, you panic. With Inner Warden you get: the process that initiated it, the parent process tree, the binary's hash, the destination IP and ASN, whether the binary was modified recently, and a triage summary.
That is the difference between "I have to call someone" and "I can decide this myself in five minutes". Most founders we talk to went from actively dreading their own alerts to glancing at them and going back to dinner.
The honest catches
Inner Warden does not stop you from shipping a vulnerable code path. It does not replace backups. It does not handle DDoS at the network layer (your VPS provider does, and the optional Shield module helps if you self-host). It will not save you from a stolen GitHub token. It is a host security layer, not a magic shield.
For a wider view of where it fits, see the self-defending server thesis.
Read more: Secure your VPS in 10 minutes