Day one

First 30 minutes.

From curl | sh to a hash-chained audit row of a verified detection — usually inside a quiet afternoon. This page is the day-one path, written for someone who already runs Wazuh, Suricata, or Microsoft 365 and wants to know whether the install is worth their Sunday.

Quick reality check

Install size

~80 MB binary. Single file. No daemons.

Hardware minimum

2 vCPU / 4 GB RAM for Free tier · 4 vCPU / 8 GB for Pro · 8 vCPU / 16 GB for Business

Disk

~5 GB for the engine + lifecycle store. Audit chain grows ~50 MB/day at moderate volume.

OS support

Linux x86-64 + ARM64 (Ubuntu 22.04+, Debian 12+, RHEL 9+) · macOS 14+ on Apple Silicon (post-launch)

License check

Monthly soft heartbeat, off-switchable. See /architecture for the full payload spec.

Update cadence

Stable release every 2–4 weeks. Run `cybercli upgrade` to pull the latest signed binary from GitHub Releases — your config, vault, and audit chain are preserved. Re-running `curl -sSfL https://cybercli.com/install.sh | bash` does the same thing.

Support SLA

Free: community + best-effort · Pro: 48h email · Business: 8h priority email + Slack · Enterprise: dedicated CSM, 99.9% SLA.

Backup/restore

`cybercli backup` snapshots your config + audit chain + lifecycle store into a single .tar.gz (chmod 600). `cybercli restore <path>` brings it back on the same or a fresh machine. For bigger fleets, the directory layout is restic/borg-friendly.

Daily smoke cron

Wire `cybercli check` into a systemd timer so a green light on Monday's report means every probe still passes. Two-tier cadence recommended: daily `cybercli check --engines --report json --output /var/log/cybercli/check-$(date +%F).json` runs the engine-only trio (L0+L3+L5) — fast, ignores routing/provider/channel config. Weekly `cybercli check --report json --output /var/log/cybercli/check-weekly-$(date +%F).json` runs the full 6 layers and catches routing/provider/delivery regressions (Guild role drift, Slack token rotation, channel suppression breaks) that the engine-only mode hides. Exit codes: 0 = all green, 1 = probe failed, 2 = runtime broken. systemd flags the unit on non-zero; your existing alerting picks it up.

The 30-minute path

Four steps. Real commands. Real timings.

Each step shows you what to run, what changes, and what you'll have at the end of it.

0–5 min
1. Install + init

Single-binary install. No daemon to register, no database to provision. Works fine over SSH on a fresh Ubuntu 22.04 LXC or a Mac Studio.
Commands
```
curl -sSfL https://cybercli.com/install.sh | bash
cybercli init                              # ~30 seconds, asks 3 questions
cybercli activate '<paste-the-code-from-your-welcome-email>'
```
What you have at the end

A working `cybercli` CLI in your $PATH, license verified offline, ready to onboard a connector.
5–15 min
2. Onboard your three highest-signal connectors

If you already run Wazuh, that's connector #1. If you have UniFi or pfSense for the perimeter, that's #2. If you're on Microsoft 365 for identity, that's #3 (Pro tier). The onboard flow asks for credentials, validates the connection, and starts the event stream — typically 2–5 minutes per connector.
Commands
```
cybercli onboard wazuh
cybercli onboard unifi   # or pfsense / suricata
cybercli onboard m365    # Pro+
```
What you have at the end

Live event stream from three sources flowing into the Beacons engine. The dashboard's CYCON panel shows non-zero event counts on first refresh.
15–25 min
3. Start the dashboard + wire your first notification channel

Launch the dashboard locally — it's a single-process web UI on 127.0.0.1 with no inbound port to expose. Add a Slack webhook (or SMTP, or Pushover) through the Notifications panel; the channel test fires a synthetic alert and you watch it land in the destination. Then leave it running and let the live stream flow; the engine will triage the first real signal and route the elevated ones through the channel you just configured.
Commands
```
cybercli dashboard serve   # opens http://127.0.0.1:8090
# in another shell — pick whichever feels natural:
cybercli channels add slack            # interactive CLI
# or use the dashboard's Notifications panel
cybercli channels test slack           # confirm it works
```
What you have at the end

First live notification from your environment. You've seen the full ingest → Warden → Herald loop end-to-end.
25–30 min
4. Run the read-only smoke checks

Before you wait on real traffic, run two smoke commands. First, `cybercli smoke --yes-i-mean-it` probes every onboarded connector's credentials and network reachability — read-only, no events injected. Then `cybercli check` exercises the engine itself: it injects a canned scenario through the live pipeline, watches CYCON elevate, confirms the AuthorityBridge enforces the trust ceiling, asserts every test-flagged notification stayed silent, and verifies the hash chain held across the session. Both commands write real audit-chain rows so you can re-verify everything later.
Commands
```
cybercli smoke --yes-i-mean-it     # connector + provider auth probes
cybercli check                     # engine smoke (L0..L5)
cybercli check --report html -o check.html   # for sharing
# follow the live CYCON dial in the dashboard once real signals arrive
# the dashboard's Audit tab streams the hash-chained log
```
What you have at the end

Both commands print ALL GREEN or PASS WITH WARNINGS (L2 will WARN until an AI provider is selected — that's expected on Free first installs). The next real event flows through the full ingest → triage → notification chain end-to-end, and the Audit tab records a signed entry for each step. `check.html` is your shareable receipt — friends, MSPs, and CISO reviewers can verify the engine without trusting our marketing.

For Wazuh / Suricata / M365 operators

From Wazuh to CyberCLI in 30 minutes.

You don't throw anything out. Wazuh keeps doing what it does — endpoint truth, FIM, rule-based detection. CyberCLI reads its alert stream over the Wazuh indexer/API and adds the agentic layer on top: Warden classifies and triages, Knight verifies the high-signal hits, Marshal sequences containment plans, Paladin executes the approved one-action contains via the Wazuh agent itself. Your Wazuh rules keep firing; CyberCLI just turns the alert firehose into a case lifecycle.

What stays the same

• Your Wazuh manager + agents
• Your custom Wazuh rules
• Your existing operator workflow
• Your endpoint inventory

What changes

• Alert noise → triaged cases
• Per-event handling → per-case lifecycle
• Manual containment → AI-proposed (your approval)
• Postmortem writeup → Scribe (Business+)

Same shape applies for Suricata (read EVE-JSON), pfSense/OPNsense (read filterlog), Microsoft 365 (read Graph + Defender alerts). You keep the substrate; CyberCLI gives you the operator-AI loop you didn't have time to build.

After minute 30

What gets better, and how fast.

The first 30 minutes is a vertical slice. The product gets meaningfully better over the next 90 days as you tune false positives, expand connectors, and let the local-LoRA layer learn your environment.

Day 1 → Day 7

Tune the noise floor

Warden ships with reasonable defaults but every environment is different. Mark recurring alerts as known-noise from the signal detail drawer; the engine baselines the pattern and stops counting future matches toward CYCON. Notification volume drops as the noise floor is acknowledged — exact rate depends on your environment.

Day 7 → Day 30

Widen the substrate

Add the next four to six connectors that map to your stack — Keycloak, ClamAV, Falco, Suricata. Each one expands the cross-substrate correlation Warden runs on every event. Coverage on the MITRE matrix grows roughly linearly with connector count for the first 10 connectors.

Day 30 → Day 90

Open the leash

Once you trust the engine's triage, walk Trust Ladder ceilings up per-template at your own pace. Pro tier caps at L4 (single-action sequencer with operator approval); Business caps at L7 (multi-action plans with one-approval-per-plan). You set the pace; the engine never escalates itself.

2026-06-20 doctrine

Triage any signal in one click — no AI wait.

Other tools queue your buttons behind their AI. CyberCLI flips it: every signal row in the dashboard has three buttons — ignore, monitor, investigate — that fire the moment you press them. AI doesn't gate your decision; your decision overrules AI's for CYCON math. The button press also writes a labeled TriageDecision row that the v1.5 local Warden trains on, so your judgement compounds into a model that reads your environment your way.

ignore — drops the signal out of CYCON math + auto-creates a matching suppression rule.

monitor — keeps it visible at suspicious-inconclusive without an escalation.

investigate — opens a Case + locks the signal's severity in CYCON until the case closes.

What happens when Warden gets it wrong?

You hit the ignore button on the signal row (or mark the case false-positive in the drawer). Two things happen: (1) the same connector + rule + actor pattern is suppressed by Warden's prefilter going forward, scoped to your tenant only, and (2) the false-positive lands in the per-operator training corpus we use to inform per-environment LoRA refreshes as the Cyber Guild Stable matures (v1.x). Your suppressions are local, signed, and revocable. They're not shared with us or other operators.