You know the ritual. Kick off a Yocto build for a your device, then go make coffee, because you have hours ahead of you, a full day if the cache is cold. You babysit it, it falls over two-thirds of the way through on a recipe you never touched, and you start it again before lunch.
In that same window, before the Yocto build is even a third of the way done, I can take you from an empty project to a secure, immutable image running on the board in front of me. Install, build, provision. A few minutes, no build server required.
That gap, days versus minutes, a dedicated build server versus a laptop, a systems team versus one engineer is what Avocado Desktop closes. With Avocado 1.0, it ships.
Every embedded team we talk to is living some version of the same story.
You build your proof of concept for your NVIDIA Jetson using Ubuntu and Jetpack, because it is familiar: packages install with apt, containers run, things are running. Then comes the scale transition, and the ground shifts under you. You cannot provision ten thousand devices in the field the same way you were updating the 3 devices on your desk. The mutable rootfs that made development easy is now producing a slightly different behavior on every device in the field. The security posture that did not matter at the prototype stage is suddenly non-negotiable.
So you do what serious teams do? You move to Yocto. Congratulations you now have to build and maintain your own operating system, BSP, device tree, and kernel patches. Also you need to learn the Yocto build system. Also you need to buy at least one $10k build server. Also it can't be just you so you need to hire a small team of people or contractors. You are now operating on timelines measured in quarters.
And every project has the one person who just debugs the build. They disappear for six weeks and emerge with a custom image that works, but now your whole team's velocity runs through them. An application developer wants to add a service? That is a two-day integration cycle through the Yocto expert. Picture handing that to your data scientists: you know Python? Great. Now let me show you Yocto.
Most teams escape by bolting containers on top, not because containers belong on every embedded device, but because they are the only way to let a developer declare a dependency without filing a ticket with the systems team. I have never met an embedded engineer who actually wanted to run web containers on their robot. They were told to or felt this was their only option.
That is the trap. The familiar path is fast but it cannot ship. The rigorous path can ship, but only through a single Yocto expert and a slow build server. Either way, the operating system, the part nobody set out to build, becomes the critical path to ship.
We built Avocado OS so you never have to make that trade. And now with Avocado Desktop, you’re able to ship even faster.
Avocado Desktop composes, programs, and provisions embedded Linux from your laptop, on real hardware, in minutes.
Start with the capability that surprises people most: you can program real hardware from a Mac. That sounds minor until you have fought it. Many targets, Jetson especially, expect a specific Ubuntu host just to provision, and Docker Desktop's peripheral handling gets in the way of USB. Historically you needed a dedicated Linux box with the right drivers just to flash a board, and I was not willing to keep engineers chained to the lab bench for that. So Desktop runs a full virtual machine with native USB access, and that VM is itself Avocado OS — you are running Avocado to ship Avocado. Flash a Jetson, or a Pi 5 in gadget mode, from the couch.
Everything below the surface is the same CLI and MCP server you can drive directly, so if you want to live in the command line, nothing here stops you. It is built in Rust with Tauri, it runs on macOS today with Windows and Linux landing with this 1.0 rollout, and it carries a built-in serial monitor and terminal, so a device's boot logs are right in front of you when something misbehaves.
Everything in an Avocado project is driven by a single declarative file: avocado.yaml. It is embedded infrastructure as code. It names your targets, defines your runtimes, and lists the extensions that compose your operating system.
The workflow is three steps. (1) install resolves and fetches everything from our package feeds in a few minutes, because we ship pre-compiled binaries, not a recipe. (2) build cross-compiles your code and composes your extensions into signed images, on a basic laptop, in seconds to minutes. (3) provision flashes the signed, immutable image to your hardware.
Avocado tooling is fast because we are built on Yocto under the hood and pre-compile the universe of packages ahead of time: tens of thousands per target, delivered as binaries. We build Yocto so you do not have to. The tooling is so resource light, we can run install, build, and provision on a Raspberry Pi that is running avocado cli; that is how little it asks of your machine.
You are building your runtime, which consists of extensions. An extension is a standard Linux systemd system extension, not something we invented. Your app is an extension. A camera dependency bundle is an extension. They are individually signed, reusable across projects, and composed into your root filesystem at early boot.
Avocado ships an MCP server, so a coding agent can drive the platform directly. You describe what you need:
"Add GStreamer and the kernel modules for my USB webcam to the dev project."
The agent queries the package graph, finds the modules and dependencies, wires them into your runtime, and runs the install. Point it at your existing Dockerfile and it will hand you a coverage report of what is already supported, then stand up a reference for your stack.
One decision here matters more than any other: our agent mutates the config, not the device. I have heard the alternative pitched: put an agent on the device and let it mutate the runtime in place. That is how you end up with a golden image and a shrug: here is what is running, good luck reproducing it. With Avocado, the agent edits avocado.yaml, which produces the runtime, so you always have a version-controlled record of what changed and why. Reproducible by construction, and it checks in for the whole team to follow.
It works this well because underneath, this is a standard Linux system the agent already understands, and our MCP consults our open-source docs before it suggests anything. The context it reasons from is the actual source of the OS, not a guess at an API. That is why the loop is fast, and why it makes so few mistakes.
Field noteOne plain-English message to Avocado Desktop's agent, and my Pi 4 was serving Prometheus metrics from a cross-compiled Rust service. See how →
Everything up to here happens on one device on your desk. Avocado Connect is how that same runtime reaches the rest of the fleet, through the same CLI you already have. It is the fleet management and device operations platform for Avocado OS: OTA updates, remote access, monitoring, and compliance tracking. A device enrolls automatically the moment you avocado provision it, so the board you flashed on your desk is already reporting in.
When a runtime is ready, avocado connect upload pushes it up, and you start an over-the-air update to whatever cohort you choose: a QA set, a beta site, a slice of production. The OTAs are diffed, so an update carries only the extension that changed and hot-swaps that service without a reboot, which is what makes a real update cadence possible over constrained cellular or satellite links. You can open a secure tunnel to any device to debug it, and if an update misbehaves, roll back to a previous runtime by its hash without a rebuild.
The detail that earns an engineer's trust: the OTA mechanism running in the field is the same one you used on your desk. What you tested behaves identically in production, because it is the same path, not a resemblance to one.
Avocado Desktop is one feature of Avocado 1.0, but it is the one you feel first.
For the engineer, your OS now enables you to ship faster. Your OS is now composed and delivered to you - your are iterating on your OS as fast as possible. This your custom OS, not a docker container. Coupling these features with native agentic tools allows you to move faster than you thought possible.
For the product lead, the OS stops being the critical path. You can move to a different hardware target without dread from your engineering team, and run many SKUs from one codebase, on a timeline you can actually commit to.
For the org, you do not hire or rent an OS team to get production-grade embedded Linux. That is the obvious saving, but it is not the real one. Your people spend their time on what differentiates you, the application, so they ship faster and trust what they put in the field. The operating system becomes solved infrastructure instead of a mountain you climb on every project.
Avocado 1.0 and Avocado Desktop are here and you can start building today with a free developer account.
But the release is the smaller story. The larger one is this: the future of embedded systems cannot depend on tribal knowledge, bespoke infrastructure teams, and multi-day build cycles. The products teams are building today are too sophisticated, and moving too fast to be held back by the layer underneath it. The software foundation either evolves with it, or it becomes the bottleneck on everything built on top.
The tools we use to build these systems have to be as capable as the systems themselves. That is the standard we are holding Avocado OS to.
It is time embedded Linux caught up. With Avocado Desktop, it has.
-Justin