One clean VM.
The whole platform runs on a single Debian VM — on your hypervisor or your cloud account. The installer brings Docker, Compose and the signature tooling with it; you bring a clean machine and one open port.
The VM
- OS: Debian 13 — the only supported OS. Every Octotor build and every production install runs on it.
- Prep: curl only — a fresh Debian install doesn't include it, so run apt install curl once. Everything else — Docker, Docker Compose and Cosign — is installed and pinned by the installer on a clean machine.
- Network: one inbound TLS port for the console (default 8443, configurable); outbound reach to the assets you manage. Details on the security page.
Sizing
| Scale | Assets | vCPU | RAM | Disk |
|---|---|---|---|---|
| Evaluation | up to 100 | 2 | 4 GB | 40 GB |
| Standard | up to 1,000 | 4 | 8 GB | 60 GB |
| Large | up to 2,500 | 8 | 16 GB | 100 GB |
Launch guidance — these numbers are being finalized against load testing. A real reference point: a production Octotor instance manages about 2,100 assets across 9 customers on a single VM, with the database's steady state under 1 GB. Beyond 2,500 assets, or across several instances, contact us and we'll size it with you.
History and job output are pruned on configurable retention windows — the defaults keep the database at the steady state shown above. Operator seats don't change the sizing: console sessions are light.
One VM means one point of failure, and we'd rather say so: while it is down, monitoring pauses — nothing on your targets is affected, and a rebuild takes the nightly dump plus your environment file.
The optional local AI assistant is the one component with an appetite: budget extra RAM for whatever model you load. With a cloud AI provider — or with the assistant off — nothing extra is needed.
What Octotor can manage
| Target | How | What you get |
|---|---|---|
| Windows — Windows 10/11 and Server 2016 or later | WinRM (default) or SSH | Full inventory, monitoring, script execution |
| Linux | SSH — any distribution with a POSIX shell | Full inventory, monitoring, script execution |
| Network devices — switches, firewalls, printers, UPS | SNMP v2c / v3 | Discovery, port maps, monitoring, attributes |
| Check Point | SSH (Gaia CLI) | Inventory, sync, interactive remediation recipes |
| Microsoft 365 / Entra ID | Graph — certificate-based, application-only | Users, devices, licenses, sign-in state |
| Active Directory | PowerShell on your domain controller (WinRM) | Users, computers, group sync |
| macOS | SSH + custom toolkit scripts | Monitoring, remote commands, script-driven inventory |
| Embedded Linux — QNAP and other NAS and appliance systems | SSH | Inventory and control through tailored toolkit scripts |
| Anything with SSH | Tailored scripts — today's AI assistants draft them from a plain-language prompt | Whatever the device can tell you or do |
| Anything with an IP | Ping · TCP checks | Up/down monitoring, alerting |
The last rows are the point. A user-expandable toolkit over SSH and WinRM means end-device support is effectively open-ended: your team writes a script once — minutes, with an AI assistant drafting from a plain-language prompt — and it becomes a first-class Octotor action on every matching target. The toolkit doesn't stand still either: every build ships more of our own tested scripts, and product-specific capabilities are added for every device we meet in real fleets.
Agentless, deliberately
Nothing is installed on your targets — no agents to deploy, patch, or explain to a client's security team. The VM reaches out over the protocols above, using credentials you control, and everything it learns stays in your database.
The console
The operator console is a web app served from your VM — current Chrome, Edge, Firefox or Safari. Nothing to install on operator machines either.
Further detail on architecture, security design and deployment is available on request — security@octotor.com.