RRREAZ ROMEN
← Complete project index

Apps & Control Planes / Built / deployed

OTA Fleet Control Plane

ESP device fleet service with unique device credentials, immutable firmware artifacts, compatibility gates, rollout state and authenticated operator control.

Explore architecture
STATUSBuilt / deployed
AREAApps & Control Planes
STACK5 documented technologies
INTEGRATIONS4 connected / bounded services
01

OVERVIEW

What I built.

ESP device fleet service with unique device credentials, immutable firmware artifacts, compatibility gates, rollout state and authenticated operator control.

01

Built a local production-style OTA service for ESP devices.

02

Implemented device enrollment, unique hashed credentials, immutable/content-addressed firmware artifacts and compatibility checks.

03

Separated device authentication from operator authentication and removed browser-exposed admin bearer tokens.

02

SYSTEM ARCHITECTURE

How the system is divided.

01
Architecture boundary

Device -> authenticated OTA API -> compatibility/assignment state -> immutable firmware artifact.

02
Architecture boundary

Operator -> authenticated gateway -> OTA admin API/dashboard.

03
Architecture boundary

PostgreSQL stores fleet/release state while Caddy terminates the reviewed access path.

03

NETWORK / DATA FLOW

What talks to what.

04

TECHNOLOGY STACK

The technical surface.

01ESP32
02OTA
03PostgreSQL
04Caddy
05Device identity
05

IMPLEMENTATION

How it works in practice.

  1. 01

    Device -> authenticated OTA API -> compatibility/assignment state -> immutable firmware artifact.

  2. 02

    Operator -> authenticated gateway -> OTA admin API/dashboard.

  3. 03

    PostgreSQL stores fleet/release state while Caddy terminates the reviewed access path.

06

TESTING & VALIDATION

How I know it works.

TEST 01

Device enrollment/credential tests

TEST 02

Compatibility gate at assignment

TEST 03

Compatibility re-check at artifact request

TEST 04

Signed artifact/update path

TEST 05

Canary rollout behavior

TEST 06

Fleet dashboard/operator access

07

EXTERNAL SERVICES & DEPENDENCIES

What sits outside the core.

COREOTA Fleet Control Plane
↔Caddy
↔PostgreSQL
↔ESP32 devices
↔Gateway authentication
08

ENGINEERING EVIDENCE

Artifacts behind the claims.

01Fleet dashboard
02Device identity model
03Release state
04Immutable firmware artifacts
05Compatibility checks
06Enrollment workflow
09

BOUNDARIES / CONSTRAINTS

What the project does not pretend to solve.

—Device and operator authentication are separate

—Admin bearer token is not exposed to browser code

—Final Secure Boot enforcement still belongs on the device

10

RESULT / CURRENT STATE

What this produced.

A controlled firmware-release path with explicit device identity, rollout state and artifact integrity instead of ad-hoc binary hosting.