# 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.

> **Current availability**
> Manifest-based rollout, broad webhook integrations, and self-hosted OTA management are not generally available today.

## 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.

## 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.

### 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](https://docs.luxonis.com/software-v3/oak-apps/configuration.md).
 * 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.

### Build and run an OAK App

Learn how to create, configure, and deploy an OAK App using the current software stack.

[Build and run an OAK App](https://docs.luxonis.com/software-v3/oak-apps.md)

### Example apps

Browse example repositories and reference implementations for common OAK workflows.

[Example apps](https://github.com/luxonis/oak-examples)

### 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](https://docs.luxonis.com/software-v3/oak-apps/oakctl.md)

## 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

### Connect a device

Start the setup path for OAK4 adoption and supported self-hosted connection flows.

[Connect a device](https://docs.luxonis.com/cloud/hub/connect-oak.md)

### Manage devices

Inspect device state, remote access workflows, and OTA behavior for supported devices.

[Manage devices](https://docs.luxonis.com/cloud/features/device-management.md)

### Manage applications

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

[Manage applications](https://docs.luxonis.com/cloud/features/application-management.md)

### Integration architecture

See the recommended customer-owned frontend/backend pattern for Hub integrations.

[Integration architecture](https://docs.luxonis.com/cloud/api/guides/integration-architecture.md)