Homelab Operations | Jimmy Perron

Jimmy Perron / Systems

Homelab architecture

Logical services and data flows. Documented architecture, not live telemetry.

PUBLIC EDITION

Existing Planned Data Planned path

01 / Local platform

NAS

Application services & data

Existing

Mosquitto MQTT broker

Node-RED Flow processing

InfluxDB Time-series store

MariaDB Relational store

AI Server

Local AI & processing

Existing

Ollama Local inference

OpenWebUI AI interface

Infrastructure metrics Local platform observations

Prometheus Metric collection

Grafana Local dashboards

Local monitoring and public reporting are separate concerns.

02 / Sanitized public reporting

Publishing active

Snapshot publisher

Sanitized, allowlisted observations

OUTBOUND ONLY

Deployed

Worker API

Validates the public data feed

Existing

D1

Public snapshot storage

Existing

Blazor dashboard

Reads public snapshots via the API

Snapshot publishing is active. This is a documented deployment status, not a live health indicator.

03 / IoT · separate path

Field sensors Hardware planned

Mosquitto Service existing

Node-RED Service existing

InfluxDB / .NET IoT views planned

Simulator integration exists. The complete field-to-dashboard path is planned and separate from infrastructure monitoring.

04 / Design boundaries

Purpose-specific data Infrastructure observations and IoT measurements remain distinct.

Deliberate public output Public reporting uses sanitized snapshots, not direct access to local services.

Logical architecture This public edition describes responsibilities, not deployment or access configuration.

System path

Sensor to decision

The lab mirrors an industrial stack at a smaller scale.

Field

ESP32 · Arduino · LoRa

Transport

Wi-Fi · MQTT

Logic

Node-RED flows

Storage

InfluxDB · MariaDB

Use

Grafana · Ollama summaries (planned)

FIRST USE CASE / GREENHOUSE

Remote moisture monitoring

Distributed nodes measure soil conditions, move readings through LoRa and MQTT, preserve history, and support irrigation decisions from one dashboard.

Design for intermittent field connectivity
Keep raw measurements separate from derived status
Build alerting after baseline behavior is understood

Platform layers

One concern per layer

Every technology needs a defined job. This is a learning platform, not a container-collection contest.

Connectivity

Cloudflare validates the sanitized public data feed.

Worker API · D1

Container operations

Containerized services support applications and local processing.

Docker

Observability

Prometheus collects infrastructure observations for local Grafana dashboards. IoT measurements follow a separate planned path.

Prometheus · Grafana

Local AI

Ollama runs on AI Server. The planned AI layer will summarize collected IoT data alongside existing coding experiments.

Ollama · Qwen Coder

Development

Application experiments and repeatable infrastructure.

Git · .NET · Blazor · Python

Knowledge system

Architecture, procedures and lessons stay understandable.

Obsidian · Markdown · Git

Operating principles

An AI-native industrial platform

Protecting production throughput

The objective is to protect production throughput by identifying technology constraints before they become operational constraints.

Built for humans and AI

The real advantage of an AI-native platform isn’t necessarily that AI writes the software. It’s that the platform is built so both humans and AI can understand, operate, and maintain it.

The right order

Observability first.
Intelligence second.
Automation third.

Four layers connect infrastructure and applications to observability, AI analysis, and engineering decisions, ending in human-approved operational changes. — Read diagram text

**Infrastructure & Applications**Servers · Containers · MES · SQL · Network

**Observability Platform**Metrics · Logs · Events · Dependencies

**AI Analysis Layer**Correlation · Trends · Capacity Forecasts

**Engineering Decisions**Alerts · Recommendations · Change Reviews

Human-approved operational changes