Enterprise guide · 2026
How teams develop, run, and deploy AI on robots, drones, smart cameras, and edge devices with one unified, open-source platform.

Contents
Chapter 01
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
Develop, run, and deploy AI with three parts that behave like one product: an operating system, a developer tool, and a fleet cloud.
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.
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.
Fleet management · early preview
Manage, monitor, and update devices from anywhere: OTA update workflows, crash reporting, and OpenTelemetry-based remote telemetry as you scale from one prototype to a fleet.
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. No inbound ports, no static IPs. Fleet updates, telemetry, and crash reports from anywhere.
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
From zero to running on a device in three steps. No account required, no SD cards flashed, no SSH keys wrangled.
01
curl -fsSL https://install.wendy.dev/cli.sh | bash
02
Connect a Jetson or Raspberry Pi over USB-C. Wendy discovers it automatically. No flashing SD cards, no manual IP setup.
03
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
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
The new release writes to the B partition while the device keeps running on A. Nothing is modified in place.
2
The device boots the new slot and the agent verifies core services before committing the update.
3
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
Edge devices run in factories, clinics, and the field, with no one nearby and no network to hide behind. The platform assumes exactly that.
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. No shared passwords, no open ports.
Applications run as unprivileged 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 releases install to an inactive A/B partition. If the device fails its post-reboot healthchecks, it rolls back to the previous version on its own. No update can strand a device.
The full stack is Apache 2.0 open source, with a published STRIDE threat model naming threats, trust boundaries, and the mitigations that address each one.
Entitlements · no declaration, no access
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.
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
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 never leave 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
Quality inspection, predictive maintenance, robotics, and safety, running right on the machine at line speed. Production never waits on the cloud, and process IP never leaves the plant.

Defect detection at line speed, on the machine. No frames shipped to a server, no cloud latency gating throughput.
Vibration, thermal, and acoustic models flag bearing wear, misalignment, and drift before they stop a line.
Perception and control loops run with the deterministic, single-digit-millisecond latency a moving line demands.
PPE checks, proximity alerts, and restricted-zone monitoring keep running even fully offline.
Camera feeds, recipes, and process data are competitive secrets. Nothing crosses the firewall, air-gapped networks included.
Atomic updates with automatic rollback mean a station is never left half-updated during a shift.
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
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.
Perception, autonomy, and control run on the platform in GPS- and comms-denied environments. No cloud, no link required.
Models execute where the sensors are, with no telemetry leaving the platform.
Camera, radar, lidar, RF, and IMU streams fuse into a single situational picture on the device.
Many platforms act as one, without an operator micromanaging each unit.
A/B updates with automatic rollback mean a platform never gets bricked downrange.
Tamper-evident, on-device logs support after-action review and accountability.
Also in the stack
Step in when judgment is required, hand back to autonomy when it is not.
Device identity and workload integrity anchored in the hardware.
Operate distributed platforms as a single fleet.
UAS, UGVs, and fixed sensors in harsh environments.


Concept renders: quadruped UGV and fixed-wing UAS on autonomous patrol.
Chapter 09
Clinical-grade AI at the point of care: private, deterministic, and fully under your control, so patient data never leaves the room.
No cloud round-trip means no PHI in transit, and a dramatically simpler HIPAA and GDPR posture.
Endoscopy, ultrasound, and surgical video processed with deterministic, sub-frame latency.
The device behaves the same in validation and in the field. Exactly what regulators expect.
Evidence for design history files, audits, and post-market surveillance is captured on the device.
A monitor is never left half-updated or bricked mid-shift.
Ambulances, rural clinics, and field hospitals keep working when the network does not.

Chapter 10
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.

Plug in over USB-C and deploy with one command. Like iOS development, but for robots.
From an idea on your laptop to inference on real sensors before the meeting ends.
Swift, Python, Rust, C++, and TypeScript, with ROS 2 support. No cross-compilation gymnastics or golden SD cards.
GPU, cameras, GPIO, I2C, SPI, and audio are one entitlement away.
Same code, same stack, same device state. Publishable, repeatable results.
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
Start on hardware you already own, or start on hardware we ship ready to run. Either way, the OS is free. Forever.

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.

A field-ready kit: Jetson Orin Nano with WendyOS preinstalled, 4K camera, NVMe storage, and battery in a dust-, heat-, and water-resistant case. Runs detection workflows, from fire and smoke to intrusion alerts, fully offline.
Runs on: NVIDIA Jetson Orin Nano · AGX Orin · AGX Thor · Raspberry Pi 3/4/5 · any Linux machine via Wendy Agent
Free forever under Apache 2.0. No seat limits, no lock-in, standard OCI containers.
Wendy Jetson and Wendy Box ship ready to run, with WendyOS preinstalled and provisioned.
Fleet management for teams. Pricing announced at launch; talk to us to join the preview.

Next step
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