Enterprise guide · 2026
The enterprise guide to Physical AI
How teams develop, run, and deploy AI on robots, drones, smart cameras, and edge devices with one unified, open-source platform.
Contents
What's inside
- 01The 2 a.m. problem03
- 02One unified platform04
- 03The developer experience05
- 04Updates like a phone06
- 05Security and safety by default07
- 06Sovereign AI08
- 07Industrial & energy09
- 08Defense10
- 09Biotech & medical devices11
- 10Research & development12
- 11Hardware & pricing13
Chapter 01
The 2 a.m. problem
Most edge deployment still runs on SSH, scp, and hand-tuned scripts. It works, right up until the fleet grows.
It's 2 a.m. A robot in the field stops reporting. You open a laptop, type ssh pi@robot-07, and start poking around. You restart a service, tweak a config, apt-install a missing library. The robot comes back. Everyone goes to bed.
You have also just made robot-07 unique. Its running state is now the sum of every hand-typed session since it shipped, and none of it is written down anywhere. "Works on my machine" gets a hardware edition: works on my robot.
SSHing into 3 robots is a Tuesday. SSHing into 30 is a bad week. SSHing into 300 is impossible.
The security story is worse. If the only way to operate a fleet is to log into it, a way in has to stay open, permanently, on every device ever shipped. Shortcuts accumulate: shared keys, permitted root logins, a forwarded port 22. A fleet-wide key is a fleet-wide breach, and the blast radius has motors: a compromised robot has actuators, cameras, and a physical position in a real room.
This is not a discipline problem. It is an architecture problem, and the rest of this guide is the architecture that fixes it: describe what should run on a device, and let the platform make it so.
Chapter 02
One unified platform
Develop, run, and deploy AI with three parts that behave like one product: an operating system, a developer tool, and a fleet cloud.
WendyOS
The operating system
A hardened Linux for NVIDIA Jetson and Raspberry Pi. Headless and lightweight, with containerized apps, an immutable system image, and atomic A/B updates that roll back automatically if a boot fails.
Wendy CLI
The developer tool
A single command, wendy run, takes any app with a Dockerfile from laptop to device over USB-C or the LAN, streaming logs back live. Develop from macOS, Windows, or Linux.
Wendy Cloud
Fleet management, in beta
Reach devices from anywhere as you scale from one prototype to a fleet: enrollment with per-device certificates, a fleet inventory, remote logs and updates for each device, and tunnels with no inbound ports.
How a deploy flows
Your laptop
A Dockerfile describes what your app is built from. A wendy.json declares what it needs: gpu, camera, network. Both live in git, reviewed like any other change.
The device
WendyOS runs the app as a sandboxed container under containerd. The Wendy Agent enforces entitlements and streams logs back to your terminal.
Wendy Cloud
Devices dial home to a broker over mutual TLS, with no inbound ports or static IPs. Remote access, logs, and per-device updates from anywhere, in beta.
Build in Swift, Python, Rust, C++, or TypeScript, with ROS 2 support. Or just ship a Dockerfile.
Everything on this page is Apache 2.0 open source: the OS, the CLI, and the agent. No seat limits, no lock-in, and standard OCI containers you can take anywhere.
Chapter 03
The developer experience
From zero to running on a device in three steps. No account required, no SD cards flashed, no SSH keys wrangled.
01
Install the Wendy CLI
curl -fsSL https://install.wendy.dev/cli.sh | bash
02
Plug in your device
Connect a Jetson or Raspberry Pi over USB-C. Wendy discovers it automatically. No flashing SD cards, no manual IP setup.
03
Deploy with one command
wendy run builds your app, ships it over USB-C, starts it on the device, and streams the logs back to your terminal.
Debugging included
Set breakpoints from VS Code, Cursor, or Windsurf against code running on the device, over USB or the internet. Python debugging is injected automatically, bound to loopback.
Terminal
$ wendy run
→ Device wendyos-zestful-stork.local (USB-C)
→ Building vision-app from Dockerfile…
→ Build done in 8.4s
→ Shipping image over USB-C
✓ Running on Jetson Orin Nano — streaming logs
[vision-app] camera /dev/video0 online
[vision-app] model loaded: yolov8n (GPU)
[vision-app] inference 41 fps · 18 ms
[vision-app] detected: person (0.94), forklift (0.88)
The whole deploy loop: discovery, ARM64 build, ship over USB-C, sandboxed start, live logs. First runs build the full image; layer caching makes the next ones fast.
Case study · Jetson experiment
In a test we arranged, an MIT roboticist set up a Jetson the traditional way: 3.5 hours, more than 100 steps, and a board that still failed to boot. On WendyOS, the same person went from brew install wendylabsinc/tap/wendy and a USB-C cable to a running Python app with streaming logs in about three minutes.
MIT roboticist Claire Wang's first WendyOS deploy.
Chapter 04
Updates like a phone
Four identical robots, six months of hand maintenance, four different machines. Declarative state and atomic updates end the drift.
Robot A got the security patch. Robot B missed the window. Robot C has a hand-edited systemd unit from a long-gone contractor. Robot D still carries the debug packages someone installed at a trade show. Their current state is the sum of every package transaction and manual change since installation, and no two are alike. Wendy's answer is to stop treating devices as a barn full of pets and start treating them as cattle with identity: calibration, placement, and serial stay bound to the device; everything else is declared in git.
Fleet of pets · SSH each
The running device is the source of truth.
Every fix is a hand-typed session that nobody can replay.
Four robots, six months later: four different machines.
A way in stays open, permanently, on every shipped device.
Cattle with identity · declare state
A Dockerfile and a wendy.json in git are the source of truth.
Every change is a pull request that anyone can review.
Every device runs exactly what its declaration says it runs.
Production images ship without SSH at all.
How an OS update lands
1
Install to the inactive slot
The new release writes to the B partition while the device keeps running on A. Nothing is modified in place.
2
Reboot and healthcheck
The device boots the new slot and the agent verifies core services before committing the update.
3
Commit, or roll back on its own
A failed boot returns to the previous slot automatically. Fleet updates stop being a leap of faith.
Apps update the same way: containers are replaced whole, never patched in place, and persistent data lives on a separate partition that survives every update.
Chapter 05
Security and safety by default
Edge devices run in factories, clinics, and the field, with no one nearby and no network to hide behind. The platform assumes exactly that.
mTLS everywhere
Every connection to a provisioned device, from CLI gRPC to Bluetooth to cloud tunnels, requires mutual TLS with per-device certificates, with post-quantum cryptography for data in transit. Devices expose one authenticated management port, with no shared passwords and SSH off by default.
Apps run sandboxed
Applications run in containers with seccomp profiles and CPU, memory, and PID limits. Entitlements in wendy.json gate every capability, so an app gets only what it declares.
OS updates that roll back
OS releases install to an inactive A/B partition. If the device fails to boot or fails its post-reboot health checks, it rolls back to the previous version on its own.
Open and documented
WendyOS, the CLI, and the agent are Apache 2.0 open source, with a published STRIDE threat model and a public status for every security control.
Entitlements · no declaration, no access
A published threat model, not a promise
A public STRIDE threat model for the Wendy Agent covers spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, with named threats, trust boundaries, and the mitigation for each. It lives in the open-source repository and evolves with the code.
No SSH to defend
There is no SSH daemon on a production image. Devices are operated through the agent's mutually authenticated API, so there is no permanent login path to secure, rotate, or leak. Report vulnerabilities to contact@wendy.dev.
Chapter 06
Sovereign AI
Run AI on infrastructure you own, in facilities you control, with nothing leaving the building.
Legal, medical, defense, and financial firms increasingly cannot send prompts, documents, or camera feeds to someone else's cloud. With Wendy, they deploy models to their own on-premise servers with one command, and data, prompts, and inference stay in the building.
The same agent that runs on a Jetson runs on ordinary x86 and ARM Linux servers and NVIDIA DGX Spark. The deployment is a container plus a declaration, so the workflow your team learns on one edge device is the workflow that runs your private inference cluster.
Air-gapped by design. Devices work fully offline. Connectivity is an option, not a dependency.
Your models, your weights. Open models run under your roof, tuned to your data, on your hardware.
Auditable to the bottom. Apache 2.0 from OS to agent. Your security team can read every line that touches your data.
One workflow everywhere. The same wendy run deploys to a robot, a rack server, or a workstation under a desk.
On-premise inference: the model, the data, and the answers stay inside the firm.
Chapter 07
Industrial & energy
Quality inspection, predictive maintenance, robotics, and safety, running right on the machine at line speed. Production does not wait on the cloud, and process data stays in the plant.
Visual quality inspection
Defect detection at line speed, on the machine. No frames shipped to a server, no cloud latency gating throughput.
Predictive maintenance
Vibration, thermal, and acoustic models flag bearing wear, misalignment, and drift before they stop a line.
Robotics & cell control
Perception and control loops run on the cell itself, for the low latency a moving line demands.
Worker safety zones
PPE checks, proximity alerts, and restricted-zone monitoring keep running even fully offline.
Process IP stays in the plant
Camera feeds, recipes, and process data are competitive secrets. Apps compute locally, so that data can stay inside the plant network, air-gapped networks included.
Updates across every line
Apps redeploy in seconds, and OS updates roll back on their own if the new version fails its checks.
Nuclear
Remote inspection and anomaly detection for the hot zone, fully air-gapped.
Energy & grid
Substation monitoring, wind and solar inspection, sub-second outage prevention.
Mining
Autonomous haulage and underground SLAM in GPS- and comms-denied sites.
Oil & gas
Offshore inspection, methane leak detection, pipeline surveillance without coverage.
Chapter 08
Defense
Mission-grade physical AI for contested, disconnected environments where the cloud simply is not an option. Perception, autonomy, and control run directly on the platform.
Disconnected autonomy
Perception, autonomy, and control run on the platform in GPS- and comms-denied environments. No cloud, no link required.
On-device inference
Models execute where the sensors are, with no telemetry leaving the platform.
Sensor fusion
Camera, radar, lidar, RF, and IMU streams fuse into a single situational picture on the device.
Multi-platform missions
The same software stack and update workflow on every UAS, UGV, and fixed sensor.
Updates in the field
OS updates roll back on their own if the new version fails to boot or fails its health checks.
Mission logging
Apps and the agent log on the device, so sensor data and decisions can be reviewed after the mission.
Also in the stack
Teleoperation & human-in-the-loop
Step in when judgment is required, hand back to autonomy when it is not.
Authenticated platforms
Per-device certificates, mutual TLS, and sandboxed apps on every platform.
Remote access (beta)
Reach distributed platforms through an outbound tunnel when a link is available.
Rugged hardware support
UAS, UGVs, and fixed sensors in harsh environments.
Concept renders: quadruped UGV and fixed-wing UAS on autonomous patrol.
Chapter 09
Biotech & medical devices
AI at the point of care: private, predictable, and under your control, so patient data can stay in the room.
Patient data stays on the device
Inference runs locally, so imaging, vitals, and recordings can stay on the hardware.
Real-time imaging & vision
Endoscopy, ultrasound, and surgical video processed with low latency on Jetson-class GPUs.
Consistent behavior
The software you validate is the software that runs at the point of care.
Device logs & traceability
Apps log inputs, model versions, and decisions on the device, for your own traceability and audit process.
OS updates that roll back
A failed update returns the device to its previous version on its own.
Offline-first operation
Ambulances, rural clinics, and field hospitals keep working when the network does not.
Chapter 10
Research & development
Plug a Jetson or Raspberry Pi into your laptop, run one command, and your code is on the device with logs streaming back. Iterate on real hardware in minutes, not weeks.
A mobile-like developer experience
Plug in over USB-C and deploy with one command. Like iOS development, but for robots.
Prototype on real hardware in minutes
From an idea on your laptop to inference on real sensors before the meeting ends.
Any language, any stack
Swift, Python, Rust, C++, and TypeScript, with ROS 2 support. No cross-compilation gymnastics or golden SD cards.
Full access to sensors & GPU
GPU, cameras, GPIO, I2C, SPI, and audio are one entitlement away.
Reproducible experiments
Same code, same stack, same device state. Publishable, repeatable results.
Manage a bench full of devices
wendy discover finds every device over mDNS. No spreadsheet of IP addresses.
"48 hours of continuous, sleep-deprived coding successfully turned into an edge-deployed, cloud-connected autonomous inspector."
Chapter 11
Hardware & pricing
Start on hardware you already own, or start on hardware we ship ready to run. Either way, the OS is free. Forever.
Wendy Jetson
A ready-to-run NVIDIA Jetson with WendyOS preinstalled on a 512 GB NVMe, in a machined-aluminum enclosure. Every interface is exposed: GPIO, USB, DisplayPort, and a CSI ribbon-camera connector. From box to deploy in minutes.
Wendy Box · configure and buy
A portable field kit: full color and thermal cameras, Jetson Orin Nano with WendyOS preinstalled, NVMe storage, and battery in a hand-held, dust-, heat-, and water-resistant case. Runs detection workflows, from fire and smoke to intrusion alerts, fully offline. Configure and buy at wendy.dev/products/wendy-box.
Runs on: NVIDIA Jetson Orin Nano · AGX Orin · AGX Thor · Raspberry Pi 3/4/5 · any Linux machine via Wendy Agent
WendyOS + CLI
$0Free forever under Apache 2.0. No seat limits, no lock-in, standard OCI containers.
Hardware
Per box / moWendy Box is a per-box monthly subscription with the hardware included: grab it, set it down, and it runs on its own battery. Wendy Jetson is a one-time purchase. Both ship ready to run, with WendyOS preinstalled and provisioned.
Wendy Cloud
Contact usFleet management for teams, now in beta. Talk to us about the scope and pricing for your fleet.
Next step
See Wendy on your hardware.
Tell us about your platform and constraints, and we'll show you perception, autonomy, and control running fully on-device. Or skip the call: install the CLI, plug in a device, and run your first app in minutes. Your first deploy is a Dockerfile and a wendy.json, with no SSH session anywhere in it.
© 2026 Wendy Labs Inc · Apache 2.0