OverviewHardwareSoftwareCloud
Getting started
Fleet Management
AI & Models
Platform Integration
Organization
Advanced

ON THIS PAGE

  • Why teams use Hub
  • Monitoring a production fleet
  • When this fits
  • What Hub is doing here
  • Next docs
  • Developing a prototype or pilot
  • When this fits
  • What Hub is doing here
  • Next docs
  • Building a customer portal
  • When this fits
  • What Hub is doing here
  • Next docs

Use cases

Use this page to understand the main ways teams use Luxonis Hub today. Each scenario below highlights where Hub fits, what it helps you operate, and which docs to open next.

Why teams use Hub

Luxonis Hub is most useful when you need a shared control plane for connected OAK devices, application operations, remote access, streaming, or customer-owned integrations. In practice, the most common current patterns fall into three groups:
  • operating a production fleet
  • iterating on a prototype or pilot deployment
  • building your own customer-facing portal on top of Hub APIs and streaming primitives

Monitoring a production fleet

When this fits

Choose this model when you operate many deployed devices and need one place to inspect state, manage apps, and handle supported device-update workflows.

What Hub is doing here

  • Device visibility: Inspect uptime, network details, installed apps, and runtime status per device.
  • Supported OTA: Update OAK4 OS and firmware where that path is available today.
  • Application operations: Install, stop, update, and inspect OAK Apps remotely.
  • Operational debugging: Use logs and remote access workflows to understand device or app issues.

Next docs

Device management

Inspect device state, OTA behavior, and remote access workflows.

Application management

Install, run, update, and inspect OAK Apps on connected devices.

Developing a prototype or pilot

When this fits

Choose this model when you are validating a device/application workflow in the field and need remote iteration, debugging, and data collection while the product is still evolving.

What Hub is doing here

  • Streaming and visualization: View live outputs from your app and use the default visualizer when a custom frontend is not required.
  • Application debugging: Inspect runtime logs and validate app behavior remotely.
  • Data collection: Capture snaps and related outputs for analysis, retraining, or investigation.
  • Fast iteration: Push updated app builds and re-test on connected hardware without relying on local-only access.

Next docs

Collect data with Snaps

Capture data, metadata, and inference outputs for retraining or analysis.

Monitor logs

Inspect runtime logs to debug prototype behavior and deployment issues.

Building a customer portal

When this fits

Choose this model when your end users work in your own frontend and backend, while Luxonis Hub provides the device, app, and streaming infrastructure behind that product.

What Hub is doing here

  • Device and app control plane: Register devices, inspect state, and manage deployed apps behind your own customer-facing product.
  • Backend-mediated streaming: Use Hub APIs and streaming bootstrap flows from your backend, then connect the frontend with the derived payload.
  • Visualizer-first rendering: Use visualizer as the default rendering primitive for video, overlays, detections, and richer outputs.
  • Support workflows: Use browser-based remote access, logs, and snaps to support customer deployments.

Next docs

Integration architecture

Start with the canonical customer-owned frontend/backend pattern.

Streaming and visualizer

Use the recommended backend-mediated WebRTC flow for remote customer portals.