// DOCS
ThreatCrush Docs
Start here for the current command surface, install model, and what is already real versus what is still planned. This page is intentionally honest: supported behavior is listed separately from roadmap material.
Right now, the Module Store is the clearest first destination after the basic install/docs/housekeeping work.
Install model
Preferred install: curl -fsSL https://threatcrush.com/install.sh | sh
- Linux server → real host story, installs the CLI.
- Linux desktop → installs the CLI + desktop app.
- Windows desktop → desktop client only, connects to a ThreatCrush server elsewhere.
- macOS desktop → desktop-oriented client story.
After install, lifecycle commands are threatcrush update and threatcrush remove.
// SUPPORTED
Commands we support today
threatcrush updateUpdate the installed bundle based on recorded install mode.
Real command. On Linux server installs this means CLI. On desktop-oriented installs it can include the desktop bundle too.
threatcrush removeRemove the installed bundle.
Real command. Alias: `threatcrush uninstall`.
threatcrush uninstallAlias for `threatcrush remove`.
Real alias.
threatcrush storeBrowse the module marketplace.
Real command, but currently gated behind the waitlist flow.
threatcrush store search <query>Search modules in the marketplace.
Real command, currently gated.
threatcrush store publish <url>Publish a module from a git URL or website URL.
Real command. Fetches metadata, previews it, then publishes to the store.
threatcrush modules [action] [name]Entry point for module management.
Real command entry exists, but module lifecycle behavior is still gated / early.
threatcrush monitorReal-time monitoring command surface.
Command exists today, but product behavior is still beta-gated while the daemon/runtime catches up.
threatcrush tuiInteractive dashboard command surface.
Command exists today, but the real TUI is still planned.
threatcrush initBootstrap/configure ThreatCrush on a host.
Command exists today, but full auto-detection is still planned.
threatcrush scanCode and target scanning entry point.
Command exists today, but fully realized scanning behavior is still planned.
threatcrush pentestPenetration testing entry point.
Command exists today, but production-grade engine behavior is still planned.
threatcrush statusStatus entry point for daemon/modules.
Command exists today, with fuller runtime status planned as the daemon solidifies.
threatcrush startStart the daemon.
Command surface exists, but the real daemon/service lifecycle is still being built.
threatcrush stopStop the daemon.
Command surface exists, but the real daemon/service lifecycle is still being built.
threatcrush logsInspect runtime logs.
Command surface exists, but final logging/runtime behavior is still planned.
threatcrush activateActivate a license key.
Real command surface, currently part of the beta-gated product flow.
// PLANNED
Planned / not fully implemented yet
- Fully functional `threatcrush tui` dashboard (htop-style security interface)
- Real `threatcrush init` host auto-detection and config generation
- Daemon/service lifecycle behind `start`, `stop`, `status`, and `logs`
- Fully realized `scan` and `pentest` engines
- Production-ready module install/remove/update lifecycle under `threatcrush modules`
- Richer desktop client documentation and dedicated desktop install docs
- Expanded operator docs for Linux server deployment and hardening
// START WITH THE STORE
Why the marketplace matters first
ThreatCrush is still building out the broader daemon/runtime/operator experience. The module marketplace is the first area where contributors and early users can do something concrete today.
- Browse the ecosystem at /store
- Publish new listings at /store/publish
- Read contributor guidance at /docs/modules
// MODULE AUTHORS
Building and publishing modules
If you want to contribute to the marketplace, start with the module author docs. They explain how the store works today, what metadata we fetch, and how to publish through the web UI or CLI.