How a mini PC powers a private AI cloud for industrial safety

A mining facility at 3 AM faces a critical moment: a methane sensor in the crusher hall begins climbing dangerously. Within 5 milliseconds, the edge system flags the breach. Fifty milliseconds later, the control room screen glows red. Seconds after that, a locally hosted AI has analyzed the plant layout, identified connected zones, active equipment, and airflow patterns, and generated a precise isolation plan: shut down conveyor C4, reroute ventilation through shaft B, seal zone 7.

No cloud costs. No external AI APIs. No exposed network ports. This is the reality of HazShield AI, a distributed industrial safety platform built entirely on a single mini PC sitting under a desk. The project’s first phase focuses on constructing a genuine private cloud—powered by just 28GB of RAM—accessed securely through zero-trust networking.

A layered safety system designed for real-world pressure

HazShield replicates a complete industrial safety environment: thousands of concurrent sensor feeds—tracking gas levels, temperature, vibration, airflow, and seismic activity—stream into a Rust-based ingestion gateway. Every reading is immediately evaluated against safety thresholds. The data is stored in a time-series database optimized for high-volume ingestion, and when thresholds are breached, an AI planner springs into action to recommend mitigation steps.

The architecture hinges on a simple but powerful principle: Not all data should receive the same guarantees. The system routes every incoming reading into one of three distinct lanes, each tuned for a specific role and level of resilience.

• Hot Lane: Carries threshold violations. Delivery must occur within 50 milliseconds—no exceptions. If the message broker becomes unavailable, edge devices buffer violations to local disk and automatically replay them upon recovery. A safety system that drops alarms ceases to be a safety system.

• Warm Lane: Handles bulk telemetry. Data is batched and bulk-loaded into TimescaleDB in thousands of rows per operation. During extreme load, this lane deliberately reduces storage fidelity by sampling one in every N readings, but safety threshold evaluation always runs on 100% of the incoming data. Storage can bend under pressure; safety never does.

• Cold Lane: Reserved for AI planning. When an alarm is triggered, contextual data—sensor location, adjacent zones, running equipment—is assembled and sent to a quantized LLM running locally via Ollama. To preserve compute resources, identical hazard scenarios are deducted using prompt hashing. Fifty related sensors in an alarm storm produce one mitigation plan, not fifty.

This deliberate asymmetry ensures that resilience remains focused on what truly matters: immediate threat detection and rapid response.

The technology stack behind the private cloud

The entire HazShield platform runs on a modest hardware footprint: a single mini PC powering a compact cloud infrastructure built using mature open-source tools.

• Private Cloud: OpenStack (deployed via Kolla-Ansible) runs as a minimal private cloud on the local machine.

• Provisioning: Infrastructure is defined entirely as code using Terraform and Ansible.

• Edge Ingestion: Written in Rust using Axum and Tokio for high-performance processing.

• Orchestration: Python-based FastAPI with asynchronous workers.

• Data Layer: PostgreSQL 16 paired with TimescaleDB for time-series data, backed by Redis Streams for real-time messaging.

• AI Engine: Ollama hosts quantized local models for inference.

• Control Room: A React and TypeScript web interface powered by WebSockets.

• Public Access: Cloudflare Tunnel connects the system to the internet without exposing any local ports, fronted by a Caddy reverse proxy.

The cloud consists of just three virtual machines: an edge node managing public ingress and data ingestion, a state node hosting the time-series database and message layer, and a compute node where AI planning occurs. Each VM is sized precisely based on profiling, ensuring maximum efficiency within the tight 28GB RAM budget.

Trimming OpenStack down to fit a single machine

Private clouds built on OpenStack are typically designed to manage thousands of hypervisors, not a single mini PC. A default OpenStack deployment spins up multiple API workers per service—sometimes five Neutron servers or five Keystone workers—even when serving only one user.

By profiling the control plane container by container, the setup was streamlined dramatically. Services made redundant by Terraform (which replaces OpenStack Heat) were disabled, and worker counts were reduced to single instances. Just three lines of configuration freed over 4GB of RAM, transforming a resource-starved system into one that operates smoothly:

enable_heat: "no"
openstack_service_workers: 1

An unexpected discovery emerged from the storage layer. While validating capacity using OpenStack’s Placement API, the scheduler reported far less disk space than expected. The issue traced back to the LVM layer on Ubuntu Server, where the default installation had left 828GB of the SSD unallocated and invisible to higher-level services. A single online resize command restored nearly a terabyte of storage without downtime or reinstallation:

sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

Anyone running Ubuntu should verify their volume group—unused capacity might be hiding in plain sight.

Five public domains, zero exposed ports

One of the most impressive aspects of this build is its public accessibility. HazShield exposes five distinct hostnames to the internet:

• app.… – The control room user interface

• api.… – Manages orchestration and asset management

• stream.… – Delivers live telemetry over WebSockets

• ingest.… – Receives the firehose of sensor data

• telemetry.… – Serves Grafana dashboards for observability

Despite these public endpoints, the home router forwards nothing. Not a single port is open.

The solution lies in Cloudflare Tunnel: a lightweight daemon running inside the edge VM establishes an outbound connection to Cloudflare’s global network and maintains an open tunnel. All public traffic travels over this encrypted tunnel, terminating at a local Caddy server that routes requests by hostname. From the internet’s perspective, the local network does not exist.

This design consolidates security policies—CORS rules, security headers, request size limits—into a single configuration file, eliminating redundancy across services. Even the tunnel daemon itself runs in a hardened systemd sandbox with strict resource caps (MemoryMax=256M), no elevated privileges, and a read-only filesystem, ensuring the ingestion pipeline remains uncompromised.

Internally, the cloud’s network enforces the same principle of minimal privilege. Security groups are defined not as rigid rules, but as intent: for example, the database only accepts connections from specific services, not broad IP ranges.

The result is a compact, self-contained industrial safety system that combines the responsiveness of edge computing with the scalability of cloud architecture—all running silently under a desk, free from external dependencies and cloud costs.