IoT · Edge computing · Research infrastructure · 14 October 2026
From IoT to Edge-to-Cloud: A Resilient Architecture for Container Farming
Twenty-seven sensor nodes feed a Jetson Nano and a local server. Climate decisions remain local, while Cloudflare Tunnel makes dashboards available online without turning internet access into a control dependency.
Albert Sagala · Toba Smart Farming
The operational data path
The important design choice is not simply connecting devices to the internet. It is deciding which functions must survive when the internet does not.
27 sensor nodes
Measure spatial temperature and humidity across the container farm.
Jetson Nano at the edge
Receives observations and supplies fresh local data to the control logic.
Local storage & dashboard
Retains sensor histories, actuator states, and operational traces for analysis.
Local climate control
Commands the AC, humidifier, and CO₂ solenoid without waiting for a cloud round trip.
Cloudflare Tunnel
Publishes the monitoring service through an outbound tunnel for authorized remote access.
Why the architecture begins with 27 nodes
A container farm is small, but its microclimate is not necessarily uniform. Airflow, rack obstruction, lighting, cooling distance, and plant density can make one location behave differently from another. Twenty-seven nodes provide a spatial view that a single wall-mounted sensor cannot.
The value of this network is not the device count itself. The value is synchronized evidence: where temperature and humidity diverge, which zones recover slowly, and whether an actuator improves the whole room or only the area near it.
Why control stays at the edge
The Jetson Nano sits close to the physical process. Fresh sensor values can be evaluated locally and translated into commands for the AC, humidifier, and CO₂ system. This avoids making a safety-critical climate loop depend on internet latency or cloud availability.
The practical rule is simple: the cloud may support visibility, reporting, and model development, but the container must remain controllable when the WAN link fails. An internet outage should remove remote visibility—not stop climate regulation.
Local storage creates an auditable experiment
Sensor readings alone are insufficient. The system also records actuator status so researchers can reconstruct cause and effect: when the AC switched, how humidity responded, whether CO₂ injection coincided with lighting, and how long spatial recovery took.
Keeping time-series data locally reduces bandwidth dependence and preserves high-resolution records. It also enables later comparison of rule-based, PID, or learning-based controllers using the same evidence trail. Clock synchronization, node identifiers, missing-data flags, and actuator acknowledgements should therefore be treated as research data—not implementation details.
What Cloudflare Tunnel actually does
The local dashboard is made reachable online through Cloudflare Tunnel. The cloudflared connector initiates outbound connections, so the origin does not need a publicly routable IP address or an open inbound port. A public hostname can then be mapped to the local monitoring service.
The tunnel is an access path, not the database and not the control algorithm. That distinction matters. If the tunnel is interrupted, local collection and control should continue. When connectivity returns, remote monitoring becomes available again without changing the control loop.
Security boundary: monitoring is not control
Remote dashboards should be read-only by default. If remote commands are ever enabled, they require stronger identity checks, role-based authorization, audit logs, rate limits, safe command ranges, and a local interlock that can reject unsafe requests.
A tunnel reduces direct network exposure, but it does not automatically make an application safe. Protect the hostname with an access policy, patch the dashboard and cloudflared, separate monitoring credentials from control credentials, and never expose raw device brokers or databases directly.
A reusable pattern for other smart farms
This architecture scales conceptually even when the hardware changes: distributed sensing, local decision-making, durable local records, and controlled remote access. A Raspberry Pi, industrial PC, or other edge computer can replace the Jetson if the workload does not require its GPU.
Start with reliability before adding AI. Verify sensor health, timestamps, watchdogs, manual override, fail-safe actuator states, and recovery after power loss. A sophisticated model running on an unreliable data pipeline is not intelligent control; it is an unverified risk.
Implementation checklist
Unique node ID and synchronized timestamp
Local buffering during network interruption
Sensor-quality and missing-data flags
Actuator command plus acknowledgement logging
Manual override and fail-safe actuator states
Read-only remote dashboard by default
Authenticated Cloudflare access policy
Backup, retention, and recovery test