Fleet Management
AI & Models
Advanced

ON THIS PAGE

  • Why it matters
  • Mental model
  • Core capabilities in practice
  • Core concepts
  • Device
  • OAK Agent
  • OAK App
  • Integration and management boundary
  • Related guides

Luxonis Hub Overview

Luxonis Hub is the OAK-centered control plane for connecting devices, managing applications, opening remote operator sessions, collecting snaps, and integrating those workflows into your own software. Use this page to understand the core operating model before you move into setup, fleet operations, app management, or customer-facing integrations.

Why it matters

Hub is designed to remove the shared infrastructure work around real OAK deployments. Instead of building your own device-management, remote-access, and app-operation layer from scratch, you can use Hub to operate devices, run applications, collect data, and connect those workflows into your own backend and product.

Mental model

Think of Luxonis Hub as four connected layers:
  • Devices provide the physical runtime environment.
  • OAK Agent connects supported devices into Hub and manages the local app/runtime bridge.
  • OAK Apps carry the application logic, configuration, and optional frontend.
  • Your product and backend can integrate Hub APIs and streaming primitives into customer-facing workflows.
Concept diagram showing devices, agent, apps, and Hub

Core capabilities in practice

  • Device management: Track device status, connectivity, software versions, and remote-operability details.
  • Application lifecycle: Install, update, stop, and inspect OAK Apps on managed devices.
  • Remote operations: Use Web Terminal, live logs, and remote visualization when local access is not available.
  • Data collection: Capture snaps and related outputs to support debugging and model improvement.
  • Customer integration: Connect Hub into your own backend, frontend, and operational systems.
  • AI and models: Manage models in Hub and convert them for deployment on Luxonis hardware.

Core concepts

Device

A Device is the physical environment where the OAK Agent runs.In practice, that is usually one of these:
  • A Series 4 camera with the agent already installed.
  • A supported Linux host, such as a NUC or Jetson, where the agent is installed and supported OAK devices are attached.
Devices appear in the Hub UI where you can inspect state, review software versions, deploy apps, and open remote sessions for debugging or operations.
Device overview page in Luxonis Hub
Example device detail view in Luxonis Hub.

OAK Agent

The OAK Agent is the runtime bridge between the device and Luxonis Hub. It handles device discovery, app deployment, remote-session plumbing, log transport, and data upload.
  • On Series 4 devices, the agent is part of the supported Hub-managed path.
  • On self-hosted Linux deployments, the agent connects the host and attached hardware into Hub.
For self-hosted deployments, the host operating system remains customer-managed. Hub's intended management boundary is the oak-agent and application layer, not full host lifecycle management.

OAK App

An OAK App is the containerized unit you deploy and operate through Hub. It bundles your runtime logic, configuration, and optional static frontend into a deployable artifact for supported devices.
  • It is configured through oakapp.toml.
  • It can expose a static frontend or fall back to Hub's default visualizer path.
  • It can emit logs, stream outputs, and produce snaps or other collected artifacts.

oakctl

oakctl is the main local CLI for OAK App development and nearby device work. Use it to build apps, run local iterations, inspect devices during development, and publish app artifacts into Hub.Learn more about oakctl

Integration and management boundary

For customer-facing products, the default integration model is:
  • customer users -> customer frontend -> customer backend -> Hub APIs and streaming primitives
That means:
  • customer auth stays customer-owned
  • Hub API keys stay in your backend only
  • your frontend receives only the derived payload it needs for sessions or visualization
This is especially useful when you are building your own portal or operational backend around Luxonis hardware instead of relying only on the Hub UI.

Related guides