Selected Work / Project

Secure Rust IoT Gateway from Edge to Cloud

Author: Thomas Bonderup Published: Focus area: Secure Edge-to-Cloud IoT Delivery

Built a production-oriented Rust IoT gateway that preserves telemetry across network failures, enforces secure edge-to-cloud transport, and gives operators real observability in daily operations.

Why this project matters

Context over abstraction

These projects show the technical environment, delivery pressure, and system constraints surrounding the work.

Decisions should be traceable

The useful part is understanding which architecture or implementation choices mattered and why they were taken.

Proof should be reusable

A strong project write-up leaves behind code, patterns, and lessons that another engineer can evaluate quickly.

Secure Edge-to-Cloud IoT Delivery IoT Gateway Rust Security
Built a production-oriented Rust IoT gateway that preserves telemetry across network failures, enforces secure edge-to-cloud transport, and gives operators real observability in daily operations.

Project snapshot

Challenge

Edge environments had unstable connectivity, constrained devices, and mixed protocols, which created telemetry loss risk and weak operational visibility when incidents happened.

Constraints

  • The gateway had to survive intermittent network outages without losing telemetry.
  • Security controls needed to be explicit across MQTT/HTTP boundaries and cloud egress.
  • Operations needed traceable health and metrics, not only logs and dashboards screenshots.

Intervention

  • Designed a Rust-based gateway with MQTT and HTTP ingest paths, deterministic routing, and durable WAL buffering.
  • Implemented at-least-once delivery flow with WAL state transitions, retries, backpressure controls, and replay support.
  • Added observability primitives with OpenTelemetry traces, Prometheus metrics, and health/readiness endpoints.
  • Hardened the edge-to-cloud path with TLS/mTLS patterns, typed configuration, and safer operational defaults.

Outcomes

  • Telemetry delivery became resilient under outages through durable buffering and controlled retry behavior.
  • The gateway architecture became auditable end-to-end with explicit boundaries, interfaces, and runtime deployment model.
  • Operations gained faster incident debugging through built-in traces, metrics, and service health probes.

Context

This project documents a secure Rust IoT gateway used to move telemetry from STM32 edge devices to cloud services with reliability and security by design.

The current reference deployment runs the gateway on a Raspberry Pi 5 edge host, which gives enough CPU, memory, and local SSD bandwidth for MQTT ingest, SQLite WAL buffering, and observability workloads in a compact field setup.

For the full technical deep dive, see the blog section on system context and scope.

Intervention

I implemented the gateway as a reliability-first ingest plane with clear responsibilities:

  1. Ingest telemetry through MQTT and HTTP interfaces.
  2. Normalize payloads and enrich records with gateway metadata.
  3. Persist records to a local SQLite WAL before cloud forwarding.
  4. Dispatch with controlled retries, acknowledgements, and dead-letter recovery paths.
  5. Expose health, metrics, and traces for operators and CI checks.

Implementation details are documented in:

Evidence

The gateway architecture produces operational evidence that teams can act on:

  • Durable WAL state progression from Enqueued to InFlight to Acked/Dead for message lifecycle traceability.
  • Observable ingest and publish flow via traces, metrics, and health/readiness endpoints.
  • Explicit interface boundaries for MQTT ingest, HTTP ingest, admin API, and telemetry export.
  • Deployment mapping from constrained STM32 devices through edge host runtime to cloud observability services.

Outcome

Engineering outcomes from this implementation:

  • Reliability improved through durable buffering and deterministic retry semantics.
  • Security posture improved through explicit transport/auth controls and hardened defaults.
  • Observability improved through first-class telemetry signals for incident response.
  • The architecture became reusable as a reference model for new IoT deployments and audits.

Next Step

This architecture is a reusable reference for how I think about secure edge-to-cloud delivery, reliable buffering, and operable gateway runtime design:

  • Review the deep dive for the design tradeoffs and implementation details behind the gateway.
  • Browse the wider portfolio for adjacent work in telemetry, transport, and reliability engineering.

Read the full Rust IoT Gateway deep dive or view more portfolio work.

Tech Notes

The implementation focuses on production-operable behavior rather than demo-only architecture: Rust gateway services, MQTT/HTTP ingest, SQLite WAL durability, OpenTelemetry tracing, Prometheus metrics, and secure edge-to-cloud transport patterns.

Thomas Bonderup

Thomas Bonderup

Senior Software Engineer

Specializes in IoT architecture, distributed systems, reliability and observability, edge-to-cloud delivery.

Builder notes and project references

If this portfolio entry feels close to something you're building, let's talk through the implementation details and tradeoffs.

These portfolio entries come from a mix of real delivery work, deep technical explorations, and earlier builder projects. If the constraints, tradeoffs, or implementation choices feel familiar, I can help you compare the next practical move.

Technical scope: IoT architecture, distributed systems, reliability and observability, edge-to-cloud delivery.

Explore related work or start a technical conversation

If this project overlaps with the systems you care about, continue into related work, the CV, or the contact page for hiring and technical follow-up.

Related content

Get in touch about this work

Use this for hiring conversations, collaboration, or technical follow-up.

Prefer direct contact? Call +45 22 39 34 91 or email tb@tbcoding.dk.

Best for hiring conversations, technical discussion, and thoughtful follow-up on published work.

Typical response time: same business day.