Containers
Run the right workloads in containers
ROS nodes, perception, and anything that benefits from isolation run in OCI containers, on their own release cadence — beside native services, not instead of them.
Robotics
Device infrastructure for physical AI
Your robot works. Then your systems engineers spend the next quarter on kernel drivers, flashing scripts, and an update pipeline instead of perception. Peridio is the Linux under ROS — container support, atomic OTA, a reproducible image, and a software layer that travels across the hardware you ship.
ROS is middleware.Avocado OS is the Linux distribution underneath it.
Robot Operating System is not an operating system. It is middleware, and it still needs a real Linux distribution beneath it. Avocado OS is that layer, with ROS 2 Humble and Jazzy as first-class packages.
Core jobs
Four jobs, on every robot you ship
OTA that can revert itself, and a reproducible image so the bench and the field match. Each one is a mechanism in Avocado OS and Peridio Core today, not a roadmap promise.
Atomic A/B updates on roughly 100 MB extension partitions, with automatic rollback. A failed update reverts itself, and a model, a container, or an application ships as its own extension in under a second with no reboot.
Change the kernel, the rootfs, the boot chain, and the services. Upstream and real-time kernels are prebuilt, so PREEMPT_RT is a configuration change rather than a project.
Flash and register a new unit from any laptop — macOS, Windows, or Linux — and it comes up already known to the fleet, with no dedicated Linux build machine in the loop.
One declaration produces the same signed, immutable image every time, so the unit on the bench and the unit in the field are bit-for-bit identical. Nothing outside that file decides what gets built.
Underneath all four: secure boot, dm-verity verified images, full disk encryption, and an SBOM per release. Deployments, cohorts, phased rollouts, and encrypted tunnels to a single device are managed fleet-wide in Peridio Core.
Platform flexibility
A platform you can change, not one you adopt
Containerize perception and anything that needs its own release cadence, without containerizing the whole robot. The kernel, drivers, and native services stay yours to change.
Host OS
Modify the host OS
The kernel, drivers, rootfs, and boot chain are configuration you control, not a black box you build against.
Cross-compilation
Build for the target from any laptop
Build for the target from any host laptop — macOS, Windows, or Linux — with no dedicated Linux build machine.
Native services
Run custom services with zero container overhead
Latency-sensitive control and device-facing services run natively on the host, as first-class system services.
Hardware
Built for Jetson, portable well past it
The same ROS stack, containers, OTA, and reproducible image travel from Jetson to Raspberry Pi, NXP, and x86 — without forking the layer underneath.
4
compute tiers on one software layer — from a safety microcontroller to a workstation-class robot brain.
5
silicon families featured below, with more behind the hardware support matrix.
Preferred Partner in the NVIDIA Partner Network, advising on Jetson solutions.
Registered Partner in the NXP Partner Program, featured in the i.MX 8 manifest.
Featured targets
Supported
NVIDIA Jetson
Orin Nano · Orin NX · AGX Orin · Thor
The dense-TOPS tier most robotics teams train against, from entry modules to the current robot brains.
Supported
Raspberry Pi
4 · 5 · CM4 · CM5
The board most prototypes start on, and the compute modules many products ship on.
Supported
NXP i.MX
i.MX 8M Plus · i.MX 93 · i.MX 95
Integrated NPUs and long production lifetimes, for units that have to stay buildable for years.
In progress
Qualcomm
Dragonwing IQ
Bring-up underway. Talk to us about timelines before you commit a design to it.
Supported
x86 with RTX
Intel · AMD · discrete RTX
For robots whose compute budget is a workstation rather than a module, with a discrete GPU alongside.
Also supported
More families behind the support matrix
Plus custom carriers. Explore all supported hardware targets or read the robotics compute tiers brief.
Named Best in Show at embedded world NA 2025
From a sub-1 TOPS safety controller to a workstation-class robot brain.
Reference design · Avocado OS · GOAT Racer One · NVIDIA
One race car, built the way the platform is meant to be used.
GOAT Racer One is published as a reference design rather than a result to admire: ROS on a product-specific OS, containerized perception beside native control, and repeated over-the-air deployments while the car was still being developed.
Stage 01 / 04
Build a product-specific OS
One declaration produces the image the car boots — kernel, drivers, and services chosen for this vehicle rather than inherited whole from a general-purpose distribution.
Stage 02 / 04
Split the workload
Perception runs in containers, on its own release cadence. Latency-sensitive control runs natively on the host, with no container in the loop.
Stage 03 / 04
Provision the vehicle
The signed, immutable image is flashed and the car comes up already registered to the fleet — from the same laptop the build ran on.
Stage 04 / 04
Iterate over the air
Development kept moving after the car was assembled: repeated over-the-air deployments across the build, each one atomic and each able to revert itself.
The parts worth copying are the shape of the OS — built for this product rather than adopted whole — and the split between containerized workloads and native services. Together they are what let the build keep iterating over the air instead of stopping to reflash.
each deployment is the next iteration, not a reflash
FAQ
Get started
Start operating your fleet
Bring your hardware, fleet size, and timeline.
Read the docs
Deployments, cohorts, tunnels, and the CLI, documented end to end.
Create a free account
The Developer tier is free. Register a device and push your first release.