Edge Platform & Deployment Engineer

Location: Mumbai, India

Department: Product

Experience: 1 - 3 Years

• Decide what the platform should do next. Turn field problems, support tickets and customer requests into features, set priorities, and make the trade-offs between power, simplicity and reliability.
• Design for people unfamiliar with the tech:

• Watch real users set up and run the product, find where they get stuck or need to call us, and remove those steps.
• Build new protocol apps to extend the ecosystem: take a protocol or controller we don't support yet, find the best library or vendor SDK for it, and ship a production adapter that follows our app contract (polling, packaging, install scripts, configurator, monitoring), so that every new protocol is just as easy to set up as the existing ones.
• Pick the right language for each job. Today the platform runs on Node.js, Python, C++, TypeScript and Bash, and the next adapter might need C#, Go, Java or Rust if that's where the only solid driver lives.
• Commission edge gateways at customer sites: install the device, configure the network, connect it to the PLCs, SCADA, DCS or meters, onboard it to the cloud, and confirm the data is right, not just that it's flowing.
• Read the existing OT setup before touching it: identify the assets, controllers, protocols, register and tag maps, network layout, and who owns what.
• Configure and troubleshoot the existing adapters (Modbus TCP/RTU, OPC UA, Siemens S7, Omron FINS, Mitsubishi MC, Fanuc FOCAS) and validate every value against the source.
• Maintain the core platform: the orchestrator and its web UI, the configurator, the install and uninstall scripts, and the data pipelines (Redpanda/Kafka, MQTT, HTTP).
• Own releases end to end: build, package, version, ship, and roll out to devices in the field without breaking any that are already live.
• Diagnose failures remotely and on site using logs, metrics, VPN, SSH and packet captures, then fix the root cause, not just the symptom.
• Keep deployments secure by default: segmented networks, least privilege, managed secrets, and read-only access to controllers unless writes are explicitly approved.
• Write the user guides, runbooks and site documentation that let others deploy and run the product without you.

• Engineering degree. Mandatory. Instrumentation, Electrical, Electronics, Computer Science, or equivalent.
• 1 - 3 years in industrial automation, IIoT, OT integration, systems engineering, or a field-facing technical role.
• Product sense:

• A generalist engineer, not a one-language developer:

• OT fundamentals you can apply on site:

• Hands-on with industrial protocols: Modbus TCP/RTU (function codes, register maps, byte order), OPC UA, and MQTT. Exposure to S7, FINS, MC, FOCAS, BACnet, EtherNet/IP, DNP3, IEC 61850 or IEC 60870-5-104 is a plus.
• Networking you can debug by hand: IP addressing and subnets, static vs DHCP, routing, VLANs, firewalls, VPNs, isolated or air-gapped plant networks, and Wireshark.
• Comfortable on Linux: the shell, systemd, journald, Nginx, permissions and sudo, package management, bash scripting.
• Basic IT/OT security principles: the Purdue model and network segmentation, IEC 62443 concepts, least privilege, secrets handling, and why you don't write to a running PLC without sign-off.
• Structured troubleshooting: you isolate the layer that's failing (wiring, device, protocol, network, service, cloud) instead of guessing.
• Clear written English. Your guides and site reports get read by people who weren't there, and often by people who aren't technical.
• Willing to travel to plants and work in panel rooms and on shop floors, roughly 30–40% of the time.

• Has built a tool or internal product that non-technical people actually adopted, and iterated on it based on how they used it.
• Has written a protocol driver, or wrapped a vendor library, and run it against real hardware.
• Experience with Kafka/Redpanda, Prometheus/Grafana, React or TypeScript, CMake/vcpkg, or cross-compiling for ARM.
• CI/CD and packaging (Jenkins, offline installs for air-gapped sites).
• Comfortable using AI-assisted development to get up to speed on a new language or library quickly, and to close a gap while you're still on site.
• Has commissioned a system that actually went live and stayed live, or is an ex-automation, instrumentation or plant engineer who moved into software.
• Comfortable being told the panel is undocumented, the tag list is wrong and the network is flat, and getting it working anyway.