Local Video Intelligence
Connect cameras and video feeds, run vision locally, and convert raw footage into structured observations the rest of the system can use.
Local-first computer vision automation
AI that runs the real world.
Open-source computer vision automation that runs locally. Connect cameras, local models, and triggers to turn video into structured events and workflows.
- Runs locally
- Open-source runtime
- Plugin-backed catalogs
If the embedded player still fails in this browser, open it directly on YouTube.
FAQ
Who are we?
We're Lauretta.io, builders of AI for understanding the physical world.
We were founded on the belief that effective security doesn't require pervasive biometric surveillance. That's why we focus on context and behavior before identity.
Also, we like the Jetsons, but we can't afford an Optimus.
What does Hearthlight actually do?
Hearthlight turns camera feeds and local AI models into structured detections, identities, anomaly signals, and downstream actions.
Does it run locally?
Yes. The project is positioned as local-first computer vision automation, with the runtime and control plane designed around local operator control.
How do models, triggers, and connectors fit together?
Models decide what the runtime can see, triggers decide when something matters, and connectors decide where the resulting alerts or actions go.
Can I connect this to OpenAI / Anthropic?
You can connect it to the API, but not the OAuth right now. If you do, be careful: it can get really expensive.
Where should a new user start?
Start with the Quick Start page, run `hearthlight onboard`, inspect the current inventory, and then launch the stack with `hearthlight start --interactive`.
Did this robot move by itself?
Yes. But unfortunately we can't push that skill to the main repo because it requires the robot to be tuned to the flooring material. We actually showed this at CES 2025.
Key Features
Built for practical local AI operations.
Open source
Inspect the runtime, adapt the deployment, and extend the catalogs without handing control of the physical-world AI layer to a closed platform.
Detect New actions and items without retraining
Use prompts, rules, and model choices to recognize new behaviors and objects without starting every workflow with a custom training cycle.
Ecosystem
The 3 Zoos Ecosystem
The three zoos work together as one runtime system: models see, triggers decide, and connectors act.
Model Zoo
Detection, tracking and reasoning AI models.
Explore the Model ZooTrigger Zoo
Rules, prompts, behaviors, events, thresholds, and workflows.
Explore the Trigger ZooConnector Zoo
Notifications, APIs, automations, physical systems, and external tools.
Explore the Connector ZooGet Started
From checkout to dashboard in a few explicit steps.
The first-run path is intentionally command-driven: onboard the workspace, inspect the inventory, start the stack, then open the dashboard.
pip install hearthlight
hearthlight onboard
hearthlight list-models
hearthlight start --interactive
hearthlight dashboardUse `hearthlight onboard` to prepare the local workspace, `hearthlight list-models` to inspect the current inventory, `hearthlight start` to launch the stack, and `hearthlight dashboard` to open the UI after the services are ready.
Read the Quick StartContribute
Help extend the runtime, the catalogs, and the security posture.
Hearthlight is open-source infrastructure. Contributions are welcome across the core runtime, the model ecosystem, trigger definitions, connector integrations, and the hardening work that makes local deployment trustworthy.
Architecture
A modular pipeline with a simple control plane.
The runtime stays split into focused services while the web app handles operator state, launch planning, and run visibility.
1
Ingestor
Opens feeds, runs detection and tracking, and pushes structured frame bundles.
2
Anomaly
Applies pluggable anomaly adapters and emits normalized event records.
3
Association
Infers ownership, generates incidents, and keeps resolution state coherent.
Control-plane technologies
- FastAPI API surface for run control and operations data
- React dashboard for source setup, bindings, prompts, and rules
- RabbitMQ for long-running service coordination
- Postgres for runtime and control schemas
Why it is split this way
Startup choices such as CPU vs CUDA and template selection stay on the host-side launcher, while operator-managed state lives in the control plane and survives restarts.