Cloud, deployment and monitoring
Infrastructure that only one person understands is a liability disguised as an asset. Everything we build is described in code, reproducible from an empty account, and documented for whoever is on call.
Connected products accumulate environments. Dev, staging, a customer pilot, a certification sandbox, plus whatever the firmware team spun up by hand. Without infrastructure as code, they drift, and the production incident is caused by the difference.
What the work actually involves
What we set up
- Terraform modules covering every environment, from empty account to running platform
- One-command environment creation for pilots, demos and certification runs
- Per-device certificate authority with rotation and revocation actually tested
- Blue-green or rolling deploys with an automated rollback trigger
- Cost guardrails and alerts, because chatty devices are an infrastructure bill
Monitoring that means something
- Alerts based on symptoms your customers feel, not on CPU graphs
- Fleet health as a first-class metric: devices silent, backlogged, or on old firmware
- Log aggregation with device identity attached, so one unit can be traced end to end
- Synthetic devices in production that continuously prove the ingest path works
- On-call rota, escalation policy and runbooks handed over with the system
What you get to keep
- Terraform state and modules in your account, owned by you
- Environment creation documented and demonstrated, not just written
- Grafana dashboards and alert rules as code
- Incident runbooks for the failures we can predict
- Optional managed operation under an SLA
Whichever you already run. We have delivered on AWS IoT Core and Azure IoT Hub, and on plain Kubernetes with EMQX where a customer needed to stay off the hyperscaler managed services. The device-side protocol stays the same either way.
No. Managed operation is a choice, not a dependency. The handover path is a month of pairing with your engineers, and the runbooks are written whether you take that option or not.
What this normally sits next to
These capabilities come up in almost every engagement that includes the one above.
Node.js ingestion and services
An MQTT front door, a device registry, a rules engine and clean HTTP and WebSocket APIs. Written in TypeScript, sized to your message rate, and load tested with a simulated fleet before real hardware arrives.
Device firmware and edge software
Sensor drivers, power budgets, local buffering and store-and-forward for sites with bad connectivity. Signed over-the-air updates from the first prototype, not bolted on later.
Talk to the engineers who do this work
The first call is with whoever would lead the build, not an account manager. Bring the constraint you think is going to be a problem.