Security Stack Fatigue Is Real
Walk into any SOC and count the tools. WAF, IDS, SIEM, EDR, XDR, SOAR, vulnerability scanner, API gateway, identity provider, threat intel feed, log aggregator. Each one has its own dashboard, its own alerting system, its own deployment pipeline, and its own annual license renewal that gets more expensive every year.
The average enterprise runs 76 security tools. Seventy-six. And every single one of them generates alerts that somebody has to look at, tune, and correlate. The operational overhead isn't a side effect — it's the thing that's actually preventing you from catching threats.
What a Single-Binary Actually Means
When we say single binary, we mean it literally. One executable file. You download it, you run `1sec up`, and you have a fully operational security engine with 16 modules, an embedded event bus, a REST API, and a CLI all running from that one file.
No Docker. No Kubernetes (unless you want it). No dependency on Python, Java, Node, or anything else on the host. The binary embeds everything it needs including an embedded NATS JetStream server for the event bus.
Embedded Event Bus
All 16 modules communicate through an embedded NATS JetStream instance that starts automatically. Events flow between modules in microseconds. When the Injection Shield spots a SQLi attempt, the alert reaches the AI Analysis Engine, the Auth Fortress, and the Network Guardian simultaneously. No HTTP round-trips between microservices. No Kafka cluster to manage. Just fast, in-process messaging.
Zero-Config Defaults
Every module ships with production-ready defaults. Rate limiting, detection thresholds, alert severities — all pre-configured. You can run `1sec up` on a fresh server and start catching real attacks within seconds. When you're ready to customize, a single YAML file controls everything.
Optional Rust Sidecar
For high-throughput environments, there's an optional Rust engine that handles pattern matching with Aho-Corasick pre-filtering, raw packet capture, and post-quantum cryptographic operations. It connects to the same event bus and processes events in parallel. But the Go engine works perfectly by itself — the Rust sidecar is an optimization, not a requirement.
Real-World Deployment Scenarios
The beauty of a single binary is deployment flexibility. You can run it on a $5/month VPS protecting a startup's API. You can run it on bare metal in a data center. You can run it in a Kubernetes pod using the included Helm chart.
We've seen users deploy 1-SEC in CI/CD pipelines as a security gate — run `1sec scan` against payloads before they hit production. Others run it as a sidecar alongside their application server, catching injection attempts and credential stuffing in real-time.
The deployment story is always the same: `curl -fsSL https://1-sec.dev/get | sh && 1sec up`. That's it. No infrastructure team needed. No three-month rollout plan.
CLI-First Means Automation-First
Every operation you can do through the REST API, you can do from the CLI. `1sec alerts --severity CRITICAL --json` pipes directly into jq, scripts, or your existing automation. `1sec export --format sarif` generates SARIF output for GitHub and GitLab security tabs.
Shell completions for Bash, Zsh, Fish, and PowerShell mean you're never guessing at command names or flags. Tab-complete through modules, severity levels, output formats — everything.
Security tools that can't be scripted, piped, and automated are security tools that rot. The CLI-first approach means 1-SEC fits into your workflow instead of demanding you adapt to it.