SECURITY SENTINEL — HOW I BUILT AN AI SECURITY TEAM FOR MY SERVER
How three AI layers turned a solo dev’s server into a monitored infrastructure.
I run a VPS. On it: an AI coding terminal, an image generation tool, a language learning app, and a news curation site. Five domains, three runtimes, two process managers — all on a single Ubuntu box.
The problem is simple: I’m one person. I don’t have a DevOps team. I don’t have a SOC. I don’t have someone watching Grafana dashboards at 3 AM. What I do have is a stack of internet-facing services that real people use, running 24/7.
So I built a security team — out of shell scripts, two instances of Claude, and a Perplexity subscription.
THE PROBLEM EVERY SOLO DEV IGNORES
If you run your own server, you probably know the pattern: you deploy something, it works, and you move on. Maybe you set up intrusion detection. Maybe you configured HTTPS. But ongoing monitoring? Threat intelligence? Supply-chain vulnerability tracking?
That’s where things get uncomfortable. Not because it’s impossible, but because it never feels urgent — until it suddenly is.
I already had most of the pieces scattered across the server: Telegram bot credentials from a login alert script, email configured for sending, intrusion detection running with custom jails, and nginx logging everything. What I didn’t have was a system connecting those pieces into something that could observe, correlate, and tell me when something actually mattered.
THE ARCHITECTURE: THREE LAYERS, ZERO BLOAT
Security Sentinel isn’t one tool. It’s three layers that work independently, but reinforce each other.
Layer 1: Shell scripts (every 5 minutes)
- Plain bash. No dependencies. Runs via cron.
- Checks services across two process managers: systemd and pm2.
- Monitors disk, memory, load average, intrusion detection bans, and nginx error rates against rolling baselines.
- If something crosses a threshold — a service is down, disk hits 90%, error rates spike — it sends a Telegram alert immediately.
- No AI involved. No tokens spent. Just a shell script,
jq, and acurlto the Telegram API.
This layer exists because you don’t need intelligence to know nginx is down. You need speed.
Layer 2: Claude Code (hourly + daily)
- Hourly: Claude reads the health-check JSON files generated since its last run and looks for patterns that individual checks miss — disk creeping up for hours, 401s trending across multiple services, slow-moving problems that don’t trip a single threshold.
- If nothing looks notable, it stays silent. No Telegram message. No noise.
- Daily (8:00 AM): Claude reads a threat-intelligence summary that arrived by email, cross-references it against what’s actually installed on the server, and sends a verdict via Telegram.
- The output is either “nothing actionable” or a short list of specific recommendations with exact commands to run.
The important constraint: during automated runs, Claude is strictly read-only. It cannot restart services, modify configuration, or touch anything outside its project directory. It observes, analyzes, and recommends. Action still requires a human.
Layer 3: Perplexity (daily threat intelligence)
- Every morning, Perplexity sends a scheduled email summary of recent security incidents — npm supply-chain attacks, Python package compromises, and CVEs in common server software.
- A cron job fetches this email via IMAP, extracts the content, and saves it for Claude to read.
- Claude doesn’t blindly forward the report. It checks: is this runtime even installed? Which version is on the server? Does the CVE affect this OS?
- Most days, the answer is simple: nothing actionable.
That one sentence is the most valuable output of the whole system. It means someone checked.
THE DAILY FLOW
Night: Log cleanup runs. Old reports are deleted per retention policy.
Morning: SSL certificate checks run and alert if any domain expires within 14 days.
Morning (weekly): The server verifies that unattended-upgrades is still active.
Morning: IMAP fetch pulls the Perplexity email.
Morning: Claude runs the daily scan, reads the threat report, checks relevance, and sends a Telegram verdict.
Every 5 minutes: health-check.sh writes a JSON report.
Every hour: Claude reads accumulated health data and spots trends.
On a quiet day, I get exactly one Telegram message: the daily verdict. Silence means everything is fine. Two messages means something deserves attention. Five means something is actually wrong.
THE TECH STACK
| Component | Technology | Why |
|---|---|---|
| Health checks | Bash + jq | No dependencies, no runtime, runs everywhere |
| Process monitoring | systemd + pm2 | Already managing the services |
| Threat intelligence | Perplexity scheduled email | Daily supply-chain and CVE summaries |
| Email ingestion | Python + imaplib | Fetches from IMAP and extracts the report |
| Analysis engine | Claude Code (on-server) | Reads reports and cross-references installed packages |
| Alerting | Telegram Bot API | Instant mobile notifications |
| Configuration | Plain key=value conf file | Change a threshold, behavior changes. No code edits. |
| Secrets | Separate env file, restricted permissions | Gitignored, never version-controlled |
Total new software installed: zero. Everything relies on tools already on the server — bash, curl, jq, Python 3, and Claude Code.
THE COLLABORATION MODEL
What makes this approach genuinely useful is that it isn’t one AI doing everything. It’s a collaboration between different tools, each doing what it’s best at.
- Shell scripts are fast, cheap, and reliable. They don’t hallucinate. They don’t need tokens. They check if nginx is running and alert if it isn’t.
- Claude Code on the server has context. It knows the project structure, reads health data over time, and reasons about patterns. But it’s sandboxed — read-only during automated runs, full access only when I’m present.
- Claude Code on my local machine is where I do the actual work. It designed the system, wrote the implementation plan, SSHed into the server, deployed everything, and debugged issues.
- When the IMAP fetch wasn’t finding emails because the forwarding setup preserved the original sender header instead of rewriting it, local Claude figured that out by listing the inbox and comparing headers.
- Perplexity brings external knowledge. It tracks what’s happening in the security world — new vulnerabilities, compromised packages, zero-days — so Claude can decide whether any of it matters for this specific server.
No single tool could do all of this well. Together, they cover monitoring, intelligence, analysis, and action — the four things a security team actually does.
WHAT THIS COST
| Item | Cost |
|---|---|
| Server (already running) | 5 EUR/month |
| Perplexity subscription (already had it) | Included |
| Claude Code subscription (already had it) | Included |
| New software installed | Nothing |
| npm packages added | Zero (by policy) |
| Development time | One afternoon + one morning of tuning |
| Daily token cost (Claude) | ~15,000–30,000 tokens |
| Daily Telegram messages (quiet day) | 1 |
The marginal cost of running Security Sentinel is effectively zero. Every tool it uses was already installed or already paid for. The value came from connecting them.
WHAT I LEARNED
- THE BEST MONITORING IS BORING
A good day produces one Telegram message: “nothing actionable.” That isn’t a failure of the system — it’s the point. Monitoring should be silent when things are fine and loud when they aren’t. The temptation to add more alerts, more checks, more messages is real. Resist it. Signal-to-noise ratio is everything. - LAYER YOUR INTELLIGENCE
Shell scripts catch what’s obvious. AI catches what’s subtle. External intelligence catches what you don’t know to look for. Each layer has different strengths, costs, and failure modes. If Claude goes down, the shell scripts still alert. If the internet is down, the local checks still run. - CONSTRAINTS MAKE AI USEFUL
An AI agent with unlimited permissions is a liability. Claude’s automated runs are read-only by design — enforced through project rules, Unix permissions, and restricted tool access. It can tell me “restart nginx,” but it can’t do it. That constraint is a feature, not a limitation. - REUSE EVERYTHING
The Telegram bot already existed. Email was already configured. Intrusion detection was already running. pm2 was already managing processes. Security Sentinel didn’t introduce new infrastructure — it turned existing infrastructure into a system. - AI IS A FORCE MULTIPLIER, NOT A REPLACEMENT
I still make every decision. I approve every action. I review every recommendation. But instead of manually checking services, scanning CVE feeds, and correlating log patterns, I get a daily briefing and real-time alerts. That’s the difference between “I should probably check my server” and “I know something is checking it right now.”
THE BIGGER PICTURE
If you’re a solo developer or a small team running your own infrastructure, you probably don’t have the budget or headcount for proper security monitoring. But you likely already have the building blocks: a server with logs, a messaging app for notifications, and access to AI tools.
The gap usually isn’t technology. It’s architecture. It’s deciding that these tools should talk to each other, defining clear boundaries for what each one does, and building the glue — which, in this case, was about 300 lines of bash and a well-written CLAUDE.md file.
Your AI tools are already on your machine. Your server is already logging everything. The question isn’t whether you can build this. It’s whether you’ll connect the dots.
FINAL THOUGHTS
Security Sentinel started as a practical response to a solo-dev problem: too many moving parts, not enough time, and no team watching the box around the clock. What emerged was a lightweight monitoring stack that combines speed, context, and external awareness without adding unnecessary complexity. That’s the real lesson for me: you don’t need enterprise tooling to think like an infrastructure team. You need clear roles, hard boundaries, and systems that reinforce each other.
Christian Scherling is a designer and developer at cerridan | design e.U., currently running more services than any solo dev probably should — and now, finally, monitoring all of them.