Skip to main content
Overview

System Architecture

Overview of the octoja architecture and its main components.

This article describes how octoja is built and how the individual components work together.

Overview

octoja is made up of four parts: the Agent, the platform, the web interface, and the octoja mobile app.

The Agent is installed on the devices you manage and sends data over HTTPS to the octoja platform. Devices that cannot run an agent of their own — switches, firewalls, printers, NAS boxes, ESXi hosts — are probed over the network by an agent you nominate for the job, so their data reaches the platform the same way. The platform stores what it receives, tracks how each check's status changes, and serves the web interface that you use in your browser. The mobile app carries alarms to the phones of the people on duty.

The Agent

The Agent is installed on monitored devices and is responsible for local data collection and communication with the platform.

  • Collects system metrics such as CPU, memory, disk usage, running processes, and service state
  • Runs local checks, decides whether each result is OK, warning, or critical, and sends that verdict to the platform
  • Collects hardware and software inventory
  • Installs Windows and macOS operating-system updates when a patch cycle reaches the device
  • Installs and updates software through Chocolatey, winget, Homebrew, apt, and your own packages
  • Provides remote desktop access and other remote operations
  • Probes the agentless devices assigned to it and reports their state and inventory
  • Uses outbound HTTPS on port 443

The Agent also includes an on-device app. With Show agent in system tray switched on it sits in the system tray, so people at the device can send a support request, install approved software from the Software Kiosk, and allow or decline a remote desktop session when consent is required. Support requests and the kiosk each have a switch of their own, set per device or fleet-wide through a config package. The app also delivers the notifications your technicians send and the restart prompts that come with a patch run — a hidden tray icon does not stop a consent prompt or a notification from reaching the person at the keyboard.

The Platform

The platform is the central service that receives Agent data and makes it available for monitoring and operations.

  • Receives and stores Agent data
  • Records each check result and tracks how a check's status changes over time
  • Evaluates server-side checks that do not run on the device: Device online from the connection state, plus integration checks such as Acronis Cyber Protect Cloud, Lywand Vulnerabilities, Securepoint UTM, and UniFi device from synced data
  • Raises alarms and passes them on through your alert channels, integrations, and the mobile app
  • Runs the scheduled work that is not tied to a single device: reports, patch cycle windows, and integration syncs
  • Provides the web interface

The Web Interface

The web interface is the central place where you manage your tenant from a browser. Its navigation follows the shape of the work:

  • Operations — the dashboard, cases, devices, and inventory, plus remote operations on monitored devices
  • Customers — customer records and their sites
  • Patch Management — patch cycles, the update catalog, and patch policies
  • Reporting — report templates, schedules, and generated reports
  • Configuration — config packages, the check library, custom packages, and automations
  • Administration — users, groups, access overview, tag rules, custom fields, agent deployment, branding, integrations, and the audit log

Data flow

  1. The Agent collects metrics on the monitored device.
  2. The Agent sends that data to the platform over HTTPS, and keeps a persistent realtime connection (WebSockets over TLS) open for live commands, presence, and remote desktop streaming.
  3. The platform stores the results and tracks how each check's status changes.
  4. When a status crosses what an alert rule watches for, the platform sends the alarm on — by email, into a ticketing system, or as a push notification to the octoja mobile app.
  5. Users review the current state in the web interface, which receives live updates over the same realtime channel.

Connectivity requirements

ComponentRequirement
AgentOutbound HTTPS (port 443) to the octoja service endpoint, plus a persistent WebSocket connection over TLS on the same port for the realtime channel. The Agent also downloads its own updates from the octoja CDN over HTTPS — the same source the installer comes from.
Web interfaceAny modern browser with internet access
octoja mobile appInternet access on the phone, with push notifications enabled in the app
Outbound integrationsThe platform reaches external integration endpoints (webhooks, PSA and ticketing systems, inventory sync) over HTTPS. The address you enter for a connection decides the host and port, so a system on a non-standard port works as long as octoja can reach it. Webhook URLs must start with https://.

IP addresses and firewall rules explains which destination addresses and source IPs to allow for each connection direction. Your octoja website's DNS addresses are not a list of outbound source IPs.