DEV Community: Jack Pelorus

Python, PostgreSQL, and MQTT

Jack Pelorus — Wed, 29 Jul 2026 21:09:28 +0000

Why this combination keeps winning for IoT telemetry backends — not in a benchmark, but against flaky gateways, replayed data, and firmware that never quite agrees with itself.

If you’ve ever built the backend for a fleet of IoT devices — sensors, gateways, industrial equipment reporting temperature, humidity, GPS, battery, signal strength — you’ve faced the same fork in the road early on: what do you build the ingestion layer with, and what do you store the data in?

After building a telemetry backend from scratch for a real fleet of LoRa/BLE sensors and gateways — handling dual ingestion paths, binary and JSON payload formats, automatic recovery of lost data, and a growing set of operational dashboards — I keep coming back to the same combination: Python (FastAPI + asyncio) for the API, MQTT for device transport, and PostgreSQL for storage. Here’s why that combination holds up so well for this specific problem, not just “in general.”

Full Article: https://medium.com/@jackpelorus/python-postgresql-and-mqtt-the-boring-stack-that-actually-survives-a-real-device-fleet-9297146cbe8d?sharedUserId=jackpelorus

AWS ECS Terragrunt Boilerplate

Jack Pelorus — Wed, 29 Jul 2026 15:15:26 +0000

A production-derived, multi-layer Terraform + Terragrunt setup for running containerized services on AWS ECS Fargate, behind an ALB, with blue/green deploys via CodeDeploy, a Grafana observability stack, and RDS-backed data services.

This is a sanitized boilerplate extracted from a real client deployment: the architecture, module boundaries, and CI/CD pattern are used as-is in production; all account IDs, domains, credentials, and client-specific naming have been replaced with placeholders. Ports, service names, and a couple of example task definitions (SuiteCRM, pgAdmin) are kept in because they're useful reference points for wiring up your own services, not because you need them.
Why this structure

Terraform modules describe what a resource looks like; they don't know about environments, state, or dependency ordering between layers. Terragrunt is used here to keep environment configuration (env.yaml, region.yaml) out of the modules entirely, wire up remote state automatically per layer, and express the dependency graph between layers (services depends on ecs-base and database, etc.) without copy-pasting backend blocks or duplicating variables across environments.

Github repo : https://github.com/jacksmartv/AWS-ECS-Terragrunt-Boilerplate

k6 + Playwright Load Testing on AWS

Jack Pelorus — Tue, 28 Jul 2026 15:19:49 +0000

Production-grade Terraform project that deploys a self-hosted load testing environment on AWS EC2 with Docker, Grafana, Prometheus, optional PostgreSQL, and a web GUI for running both k6 load tests and Playwright browser tests.
Architecture

k6-gui is a Flask web app that runs both test types from the browser: k6 load tests via docker compose run, and Playwright browser tests via docker compose exec into the long-running playwright-runner container (Monaco editor, real-time log streaming, HTML reports for both). See terraform/modules/ec2-k6/templates/k6-gui/README.md for details.

Git Repo: https://github.com/jacksmartv/K6-PW-test-management-platform