AEGIS: Open-Source SOAR for Indie Founders

I ran a closet pentest lab for six months. Two old workstations, a Kali box, a Raspberry Pi acting as a deception node, and a Mac Pro doing the heavy lifting. By month three I had given up on every commercial SOAR I'd tried, including the ones that advertise "for SMBs." Either the licensing math broke at the lab's volume, or the setup demanded a dedicated engineer I didn't have. So I wrote my own. The result is AEGIS — an autonomous cybersecurity platform that does what XDR, SOAR, SIEM, and deception do, in one Python codebase, on hardware I already owned.

This post is the honest version of why it exists, what it does, what it doesn't, and how you can run it tonight if you're an indie founder, a one-person security team, or a homelab operator who wants real telemetry without a quote that starts at five figures.

The price-to-value curve in commercial SOAR is broken at the bottom. There's no product designed for an operator running two servers and one CI/CD pipeline. AEGIS is what fills that gap, because the cost of not having SOAR at indie scale is now higher than the cost of running it.

Why commercial SOAR fails indie devs

The pitch decks of every major SOAR platform pretend they scale down. The reality, after I trialed five of them:

• Pricing assumes a security team exists. Per-analyst seats, per-event ingest, per-playbook execution. The cheapest plausible configuration for two people and a handful of services ran $1,200 a month before any add-ons. The "starter" tier always turns out to mean "starter for a 50-person org."
• Setup assumes integration engineers exist. Two of the platforms I tried took longer to install than to write the response automations they were supposed to run. One required a Kubernetes cluster to host the agent runners. None of them ran cleanly on a single Mac Pro without serious workarounds.
• The playbook ecosystem assumes enterprise tooling. Out-of-the-box integrations target Splunk, CrowdStrike, ServiceNow, Okta. If your stack is Vercel + Supabase + Cloudflare + Tailscale + a Discord webhook for alerting, you're writing every integration yourself anyway.
• Multi-tenant isolation costs extra. If you have side projects or you host friends' apps in the same infrastructure, you'll pay per tenant. The opposite of what an indie operator needs.

The gap between "log to stdout and hope" and "$15K/year Splunk Cloud" is where every indie dev currently lives. AEGIS is built for that gap.

AEGIS architecture in one diagram

Five components, all Python, all in one repository. Each module is a process; they communicate through a local broker (Redis by default, NATS optional). You can run all five on one machine for a homelab or split them across hosts for a small business.

┌────────────────────────────────────────────────────────────────┐
│                        AEGIS CORE                              │
│                                                                │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐  │
│  │  COLLECT │───▶│  DETECT  │───▶│  DECIDE  │───▶│   ACT    │  │
│  │  (XDR)   │    │ (SIEM)   │    │ (SOAR)   │    │(Response)│  │
│  └──────────┘    └──────────┘    └──────────┘    └──────────┘  │
│        ▲                              │                        │
│        │              ┌───────────────┘                        │
│        │              ▼                                        │
│        │     ┌─────────────────┐                               │
│        └─────│   DECEPTION     │  (honeypots, canary tokens)   │
│              └─────────────────┘                               │
└────────────────────────────────────────────────────────────────┘

• Collect (XDR layer): Pulls logs from systemd journals, Docker, Cloudflare logpush, Tailscale audit log, Supabase realtime, GitHub webhook firehose, and any HTTP endpoint that emits structured logs. Normalizes everything to a JSONL event schema.
• Detect (SIEM layer): Sigma-style rule engine plus a small set of statistical anomaly detectors. Rules can be Python functions or YAML for shareability. Ships with about 80 rules tuned for indie stacks (Cloudflare scrape detection, Supabase anon-key bulk read, GitHub Actions secret exfil, etc.).
• Decide (SOAR layer): Playbooks expressed as Python coroutines. Each playbook receives the detected event and returns a sequence of actions. No proprietary DSL.
• Act (Response layer): Integrations with Cloudflare WAF, fail2ban, Tailscale ACLs, Discord, Slack, email, PagerDuty, Linear, GitHub Issues. Adding an integration is a Python file with three methods.
• Deception (because attackers love bait): Canary tokens (PDF, AWS keys, .git directories), HTTP/SSH honeypots, fake admin endpoints. When triggered, the event flows through Detect → Decide → Act like any other signal.

That's the entire system. Five Python packages. Roughly 18K lines of code at the time of writing.

What it actually catches

Six months of operation in the lab, across five real production targets I monitor for friends and personal projects, the rule set has flagged real incidents in three categories:

1. Supply chain probes. When the npm registry surfaced suspicious updates during the CVE-2024-3094 (xz-utils backdoor) timeline, the upstream version-pinning rule fired on three of my projects within minutes — well before any CI/CD pipeline pulled the compromised version. The xz incident is the canonical example of why supply-chain monitoring belongs on every operator's checklist, even at indie scale.
2. Credential-stuffing and scrape patterns. Cloudflare's analytics will tell you "you had 50K requests yesterday." AEGIS will tell you "47K of those were from one ASN, hitting the same 12 endpoints at fixed intervals, including the rate-limit-exempt password reset endpoint." Different question, different answer.
3. Container escape probes. After CVE-2024-21626 (the runc "Leaky Vessels" escape) and the related Docker advisories, I added detection for the specific file-descriptor patterns that exploit the bug. The lab Docker host caught two probe attempts in the following month, both from scanning-as-a-service providers — not targeted, but confirming that the vulnerability was being mass-scanned within weeks of disclosure.

Setup in 20 minutes

You need: a Linux box or a Mac with Docker, Python 3.11+, and a Redis instance (the install script provisions one in Docker if you don't have one). All commands assume a fresh machine.

# 1. Clone and install
git clone https://github.com/somoswilab/aegis.git
cd aegis
./scripts/bootstrap.sh   # provisions Redis, creates venv, installs deps

# 2. Configure your collectors
cp config/aegis.example.toml config/aegis.toml
$EDITOR config/aegis.toml
# Set CLOUDFLARE_API_TOKEN, SUPABASE_PROJECT_REF, DISCORD_WEBHOOK_URL,
# and uncomment the collectors you want enabled.

# 3. Launch the stack
./aegis up
# Starts collect/detect/decide/act/deception as separate processes.
# Logs to ./logs/aegis-{component}.log

# 4. Verify
curl http://localhost:8088/health
# {"status":"ok","components":{"collect":"running","detect":"running",
#  "decide":"running","act":"running","deception":"running"}}

# 5. Trigger a test detection
./aegis test-rule cloudflare-scrape-pattern
# Synthesizes a matching event, runs it through the pipeline, posts to Discord.

That's the whole bootstrap. Most operators are running their first real detection within 20 minutes of cloning.

Writing your first playbook

The thing commercial SOARs make hardest is the thing that should be easiest: write a response that's specific to your stack. In AEGIS it's a Python function.

# playbooks/supabase_anon_bulk_read.py
from aegis.playbook import playbook, Action

@playbook(triggers=["supabase.anon_bulk_read"])
async def handle_anon_bulk_read(event, ctx):
    # 1. Yell at me in Discord
    yield Action.discord(
        channel="alerts",
        message=f"Anon-key bulk read: {event.table} from {event.ip}",
    )

    # 2. Add the source IP to Cloudflare WAF
    yield Action.cloudflare_block(
        ip=event.ip,
        zone=ctx.config["cloudflare_zone"],
        reason=f"Bulk read of {event.table}",
        ttl_minutes=60,
    )

    # 3. Open a Linear ticket for investigation
    yield Action.linear_issue(
        team="SEC",
        title=f"Investigate anon-key bulk read of {event.table}",
        body=event.to_markdown(),
    )

That's a complete playbook. Twenty-something lines of Python and you have a SOAR response — detected, decided, acted — that would have taken you a billable hour to wire up in a commercial tool.

When you outgrow it

I'll be honest about where AEGIS stops being the right answer:

• Compliance-driven environments. If you need WORM-compliant log storage, an attested audit trail, or vendor-signed playbooks, you need a commercial SOAR. AEGIS logs are append-only files. That's enough for incident review. It's not enough for SOC 2 Type II evidence (yet — there's a project plan for it, but it's not done).
• Multi-analyst workflows. AEGIS doesn't currently model an SOC analyst's queue, shift handoffs, or playbook approval flows. If you have a team of three or more dedicated to security operations, you'll outgrow it.
• Massive ingest volumes. The single-broker architecture is fine up to a few thousand events per second. Past that, you're looking at Kafka, partitioning, and a real engineer-month of rework.

For everyone below those lines — which is most indie devs, most homelab operators, and a surprising number of small-business IT teams — AEGIS is enough.

What six months of telemetry actually looks like

For the operators wondering what you actually see when a system like this is running, here is the redacted summary from the lab over a typical 30-day window earlier this year:

• Events ingested: 4.2 million across five collectors. About 60% from Cloudflare logpush, 20% from Supabase realtime, 15% from systemd journals, the remainder from Tailscale and Docker.
• Rules fired: 1,847 detections. Sounds like a lot until you remember most of them are mass scanning noise.
• Playbooks executed: 312. Mostly Cloudflare WAF blocks for repeat-offender IPs, plus a handful of Discord pages for things that needed human attention.
• Human-attention events: 9. Of those, 3 were true positives worth investigating, 6 were false positives I tuned out within a week.

The math indie operators care about is the human-attention column. Nine alerts in a month for five services and a homelab is the difference between "I will read this Discord channel" and "I will never read this Discord channel." Commercial SOARs in my trials produced two orders of magnitude more noise out of the box, which is fine when you have a 24/7 SOC and ruinous when you don't.

Honest limitations of the current release

I'd rather under-promise. The v1.4 release that's live as of May 2026 has known sharp edges:

• Cold start is unforgiving. The first 48 hours after install produce a lot of low-quality detections because the statistical baselines haven't formed. Plan to mute the Discord channel for two days, or run with the anomaly detectors disabled at first.
• Documentation lags the code. Some integrations are documented only in the source. The contributor guide explains how to read the test fixtures to understand a collector's behavior. This is improving but not solved.
• No web UI yet. Everything is CLI plus a JSON status endpoint. There's a roadmap item for a small Next.js dashboard but it's not the priority.
• Sigma rule compatibility is partial. About 70% of public Sigma rules import cleanly. The rest need field-mapping adjustments because the AEGIS event schema isn't 1:1 with the common Sigma taxonomies.

Those are the honest tradeoffs. If they're disqualifying for your use case, run something else. If they're acceptable, AEGIS will save you four figures a month and a setup weekend.

The "I want this running, but not by me" option

AEGIS is open source. The code is yours. But not every operator wants to babysit their own SOAR — even one that's designed to be low-maintenance. The deploy service is for the operator who wants the system running on their infrastructure (or on ours), tuned to their stack, with the playbooks they need pre-built, and someone reachable on a Saturday morning if something fires that they don't recognize. Pricing is per-deployment, not per-event. It's the support contract; the engine is still the open-source one.

If you want the alternative — DIY, fully self-hosted, no support contract — the repo is the thing. Star it, fork it, file issues. We read everything.

Why this matters for your own audit

SOAR isn't separate from the audit conversation. The reason the AEGIS detection rules look the way they do is because they were built from the same finding patterns that show up in indie-dev pentests. The pre-launch checklist tells you what to fix before launch. AEGIS is what watches the parts you can't pre-fix — the patterns that only appear when real attackers show up. The sample report shows what a manual audit looks like; SOAR is the running version of that, every minute, after launch.

FAQ

Is AEGIS actually free?

Yes. MIT license, no usage tier, no telemetry phoning home. The optional deploy service is a paid product. The engine is not.

Will this run on a Raspberry Pi?

The collect and deception modules will, comfortably. The full stack runs on a Pi 5 with 8GB if you're light on ingest volume and disable the anomaly detectors. For real production monitoring of more than a couple of services, plan for a small VPS or a real server.

How is this different from Wazuh or Security Onion?

Wazuh is excellent and bigger. It's an HIDS + log analyzer first, with SOAR-style response bolted on top. AEGIS is SOAR-first, designed around the playbook as the primary object. Security Onion is a distribution; AEGIS is an application you install on the OS you already use. If Wazuh fits your stack, run Wazuh. AEGIS exists for the operators for whom it doesn't.

How do I add a new collector?

One Python file in aegis/collect/sources/. Implement async def stream(self) -> AsyncIterator[Event] and yield events in the normalized schema. Register the source in the config TOML. Done.

What about LLM-based triage?

The DECIDE layer has an optional LLM step that summarizes the event and proposes a playbook if no rule matches. It's off by default because it costs money and can produce false positives. Turn it on per-rule when you have the budget.

The closet lab is still running. AEGIS catches what it was built to catch. If you want SOAR at indie-dev prices, clone the repo and run ./scripts/bootstrap.sh. If you want it deployed and supported, the deploy service exists. Either way, your infrastructure doesn't have to be naked.