Edge nodes you can update from a desk, not a truck.
A gateway in a pump station runs fine for years until it needs a patch and nobody remembers the password. We build edge deployments where software, configuration and credentials are pushed centrally, and where a node that goes offline catches up when it reconnects.
Edge computing runs workloads close to equipment, so data is filtered, analyzed or acted on locally instead of waiting on the cloud.
Cohash designs and runs edge deployments on AWS IoT Greengrass V2, Azure IoT Edge and Azure IoT Operations on Arc-enabled Kubernetes. We handle runtime selection, component packaging, fleet deployments, edge identity and certificates, and upgrades when a runtime reaches end of support.
you probably need this if
Patching a gateway means sending someone to the site with a laptop.
Application secrets are baked into the edge image and shared across every site.
Data is lost whenever a site's uplink drops for more than a few minutes.
Deployment pipeline for edge components or modules
+ 2 more documents
who does it
Edge platform engineerEmbedded Linux engineerLightweight Kubernetes engineer (K3s)
platforms
the story · edge computing
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Edge Computing, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · edge computing3 open
openPatching a gateway means sending someone to the site with a laptop.
recurringApplication secrets are baked into the edge image and shared across every site.
blockedData is lost whenever a site's uplink drops for more than a few minutes.
exposure
Runtime selectionRuntime upgrades and migrationsEdge identity and secretsFleet deployments and updatesLocal processing and…
startrehearsehandover
Site and workload survey
Reference node
Pilot sites
Rollout and operations
we are here
ready to hand over
Gateways run a supported Greengrass V2 runtime, deployed and updated from the cloud…
The fleet runs IoT Edge 1.6 LTS, supported to November 2028.
Runtime decision record with trade-offs
Reference edge node design and build scripts
chapter 01 · where it hurts
Why teams reach out
Patching a gateway means sending someone to the site with a laptop.
Application secrets are baked into the edge image and shared across every site.
Data is lost whenever a site's uplink drops for more than a few minutes.
chapter 02 · what we change
How we solve it
Runtime selection
Runtime upgrades and migrations
Edge identity and secrets
Fleet deployments and updates
Local processing and store-and-forward
chapter 03 · how it runs
Our approach
Site and workload survey
Reference node
Pilot sites
Rollout and operations
chapter 04 · where you end up
What changes
Gateways run a supported Greengrass V2 runtime, deployed and updated from the cloud, with local logic versioned as components.
The fleet runs IoT Edge 1.6 LTS, supported to November 2028.
Runtime decision record with trade-offs
Reference edge node design and build scripts
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
Greengrass nucleus or nucleus lite for constrained devices, Azure IoT Edge for container modules on a single host, or Azure IoT Operations when you want an MQTT broker and data processing on Kubernetes at the site.
IoT Edge 1.5 LTS support ends on 10 November 2026, and 1.6 LTS runs to 14 November 2028. AWS ended Greengrass V1 support on 7 October 2026. We plan and rehearse these moves on a test node before touching the fleet.
Give each edge node its own certificate, TPM-backed if possible. Have it pull application secrets at runtime instead of baking them into images. Downstream devices authenticate to the gateway and never around it.
Components and modules are versioned in a registry and rolled out a group at a time with health checks, so a bad release stops at the first site.
We do the filtering, aggregation and inference on site. Uplinks drop, so data buffers until the link returns and then replays in the right order.
capability 01 / 05in production
Runtime selection
Greengrass nucleus or nucleus lite for constrained devices, Azure IoT Edge for container modules on a single host, or Azure IoT Operations when you want an MQTT broker and data processing on Kubernetes at the site.
IoT Edge 1.5 LTS support ends on 10 November 2026, and 1.6 LTS runs to 14 November 2028. AWS ended Greengrass V1 support on 7 October 2026. We plan and rehearse these moves on a test node before touching the fleet.
Give each edge node its own certificate, TPM-backed if possible. Have it pull application secrets at runtime instead of baking them into images. Downstream devices authenticate to the gateway and never around it.
We pieced these together from Edge Computing situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Greengrass V1 gateways still running after 7 October 2026
composite · not a client story
Beforethe situation
Several hundred gateways run AWS IoT Greengrass V1, with Lambda functions doing the local filtering. V1 hit end of support on 7 October 2026. The gateways are at remote sites, and some have almost no spare memory.
What we dothe work
We sort gateways into hardware groups and pick nucleus or nucleus lite for each. Lambda functions get repackaged as Greengrass V2 components, or as generic components where nucleus lite needs that. One pilot group goes first. After it, the rest move in deployment waves with a tested rollback.
Afterwhere you end up
Gateways run a supported Greengrass V2 runtime, deployed and updated from the cloud, with local logic versioned as components.
case file 02
An IoT Edge 1.5 fleet three weeks from end of support
composite · not a client story
Beforethe situation
Support for IoT Edge 1.5 ends on 10 November 2026. This fleet runs custom protocol-translation modules on it, and the last runtime update was done by hand, one device at a time.
What we dothe work
We test the custom modules against IoT Edge 1.6 LTS on reference hardware, then script the device-side steps: stop, upgrade the container engine, install 1.6 and apply config. edgeAgent and edgeHub are pinned to specific 1.6 tags in the deployment manifest. Devices update in rings, with module health checked before each ring.
Afterwhere you end up
The fleet runs IoT Edge 1.6 LTS, supported to November 2028. Future runtime updates go through the same rings instead of manual site work.
Equipment and local devices feed an edge runtime at the site, which filters data and buffers it when the uplink is down. Deployments, secrets and identity are managed from the cloud, and processed data lands in your data platform.
01 · Site equipment
Controllers and sensorsOPC UA · Modbus → Edge runtime · OPC UA reads
Local devicesMQTT clients · BLE sensors → Local MQTT broker · MQTT
02 · Edge node
Edge runtimeGreengrass V2 · IoT Edge 1.6 → Store and forward · filtered data
Local MQTT brokerMoquette · EMQX · IoT Operations → Edge runtime · local topics
Store and forwardstream manager · disk queue → IoT endpoint · replay on reconnect
Controllers and sensors → Edge runtime: OPC UA reads
Local devices → Local MQTT broker: MQTT
Local MQTT broker → Edge runtime: local topics
Edge runtime → Store and forward: filtered data
Store and forward → IoT endpoint: replay on reconnect
Deployment service → Edge runtime: components or modules
Secrets and PKI → Edge runtime: certs and secrets
IoT endpoint → Data platform: telemetry
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Site and workload survey
For each kind of site we check hardware, connectivity, power and who can physically get to the box. And we ask what must keep running when the WAN is down.
step 02
Reference node
We build one node to the target design, with runtime, identity, monitoring and a sample workload, then deliberately break things to see how it copes.
step 03
Pilot sites
A few real sites go live and run for a while before anything wider. Whatever goes wrong there gets fixed in the reference design.
step 04
Rollout and operations
Roll the fleet out in waves. Write runbooks for upgrades, for certificate renewal and for replacing a node.
you keep
What you're left with
We write these for your Edge Computing setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
document01
Runtime decision record with trade-offs
yours to keep
design02
Reference edge node design and build scripts
yours to keep
code03
Deployment pipeline for edge components or modules
yours to keep
plan04
Upgrade plan for any runtime nearing end of support
yours to keep
runbook05
Operations runbooks for renewal, replacement and recovery
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Edge platform engineer
Embedded Linux engineer
Lightweight Kubernetes engineer (K3s)
Streaming data engineer
Edge security engineer
due diligence · edge computing
Questions to ask any partner, including us.
Put these to anyone bidding on your Edge Computing work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will a node that has been offline for a week catch up safely?
Edge sites lose connectivity. When a node comes back, store-and-forward limits, message ordering and deployment reconciliation decide whether it behaves or floods everything upstream.
Q2
How are edge credentials stored, renewed and revoked?
Gateways often carry long-lived keys in config files. Hardware-backed keys, short certificate lifetimes and a revocation path keep one stolen box from becoming a fleet problem.
Q3
If an update breaks a module in the field, what stops it spreading?
Pushing to hundreds of sites needs rings, health checks and rollback. Ask what halts a bad deployment and how quickly.
Q4
When would you put Azure IoT Operations on a site instead of IoT Edge?
IoT Operations means running Kubernetes and Arc. That pays off at multi-workload sites and is overhead for a single gateway.
Q5
Which of our fleet's runtimes have published end-of-support dates in the next two years?
IoT Edge 1.5 ends in November 2026 and Greengrass V1 already has. Runtime upgrades across remote sites take longer than teams expect.
01We're on IoT Edge 1.5. What do we need to do?
Plan the move to IoT Edge 1.6 LTS now, because 1.5 support ends on 10 November 2026. Microsoft says 1.6 doesn't bring major feature changes, so most of the work is testing your custom modules and rolling the update through your fleet in groups.
02Greengrass nucleus or nucleus lite?
Nucleus is the lower-effort path and supports features like the local shadow service, client devices and connectors. Nucleus lite suits resource-constrained devices but needs Lambda functions converted to generic components. Your hardware and feature list usually decide it.
03When does Azure IoT Operations make sense over IoT Edge?
Use it for sites with several workloads, a local MQTT broker and asset modeling on Kubernetes, assuming someone on your team is comfortable with Arc-enabled clusters. For a lone gateway forwarding telemetry, IoT Edge is usually simpler.
04Can you run AI models at the edge?
Yes, where the hardware can carry them. We ship the model as a component or module, versioned alongside everything else. When results go upstream, the inputs needed to audit them later go too.
05We still run Greengrass V1. What now?
AWS ended support for Greengrass V1 on 7 October 2026, so plan the move to Greengrass V2 now. Choose nucleus or nucleus lite per hardware group. Lambda functions can carry over as components on the nucleus, but nucleus lite needs them converted to generic components.
related
Often paired with
Projects on Edge Computing usually end up touching one of these, so they're worth a look.
