Hi there,
This is a BFD subject for sure…even on Nvidia’s board it’s a big freaking deal too. So I know a number of clients using these devices, Nvidia’s
OEM units. Like you the concern was security, it’s gotten so ridiculous that just deploying something in the field you better have a PLAN.
Seeed’s conservative stance is reasonable given the complexities of the Jetson platform. But from a product deployment and embedded systems perspective, you are also right that remote field devices need some kind of update mechanism.
The best path is not to argue “either full image only or no updates” — rather adopt a tiered update strategy:
- Minor, non-critical application updates → remote/OTA
- Security patches (in libraries/applications) → remote/OTA (with caution)
- Kernel, driver, BSP, board‐specific changes → full image update as normal
TEST EVERYTHING WELL…
By doing so you provide your users field flexibility while preserving stability and reliability.
Seeed’s caution about apt upgrade is well-founded: embedded Jetson modules involve kernel, driver, firmware, and board‐specific BSP dependencies. Without controlling the entire image, you risk system instability.”
I would Propose a hybrid strategy:
- Critical security patches: For vulnerabilities in higher‐level application layers or open source libraries, you can target remote update paths (via
apt installor container updates) only if you verify the update path does not impact kernel/driver stability. - Major OS/BSP updates: Continue to plan full image/ROM updates (via recovery mode or reflash) when moving between major JetPack versions, adapting board support changes, etc.
- OTA image‐based update infrastructure: Invest in an OTA framework that supports your products — e.g., use a solution like Mender or similar, which is known to support Jetson platforms. Mender+1
- Design the devices for field robustness: Use A/B rootfs, rollback capability, health monitoring, staged updates, remote diagnostics.
- Document update policy: Provide your customers with clear guidance what can be updated remotely and when a field service will be required.
- Set realistic expectations:
- Emphasize that no update path is risk-free. Suggest scheduling updates during low usage windows, backing up config, testing in pilot fleets, etc.
- Make clear that occasional full reflash may still be required — and budget/plan accordingly.
- the Jetson ecosystem itself supports OTA update mechanisms. NVIDIA Docs+2Mender+2
There are ways to achieve both, But it would require additional work and infrastructure (OTA update server, image‐creation workflow, field validation and rollback strategy). It isn’t impossible, but it’s not simply running apt upgrade and calling it done.”
One good thing about it being installed inside a robot, Now way to physically infect the platform 
You can’t even get to it without disassembling the thing. 
They lean Heavy 
on the security of the network instead.
Great subject and I don’t think anyone has thought far enough ahead IMO but the seeedineers are always Working on it So , stay tuned more ahead I’m certain.
HTH
GL 
PJ 