Yocto is a build system for assembling custom Linux distributions from source. If your actual goal is narrower (get an application onto a fleet of devices and keep it updated), a lot of Yocto’s machinery is cost you carry without using. This post looks at where that cost shows up and how a declarative, NixOS-based workflow with Thymis trades it off.

Why teams look for a Yocto alternative

The Yocto Project is powerful, and that power is the point: it’s a toolkit for building fully custom distributions, built for teams with dedicated embedded Linux engineers. When you “just” want an application running reliably on devices, several costs are hard to avoid:

A steep learning curve. A recipe is a mix of Python, shell, and BitBake syntax, sitting on top of bbappend files, overrides, classes, and layer precedence. Changes that look trivial (add a service, patch a package, flip a kernel option) often depend on knowing where in the layer stack a variable was last set. Onboarding an engineer into an existing Yocto tree is measured in weeks, not days.

Long builds, large artifacts. A working tmp/ and sstate-cache easily pass 100 GB. Clean builds take hours; even incremental builds are long enough to break a feedback loop. CI needs real disk and a warm shared sstate cache to be usable, and a cold cache after a release or host change drops you back to multi-hour builds.

Fragile BSP layers. Vendor BSP layers often pin kernels and bootloaders that are already years old. Each Yocto upgrade means re-checking whether your patches still apply and who maintains each component. That maintenance never finishes; it stays attached to the team.

Updates and security aren’t included. Yocto’s job ends at a built image. Getting that image safely onto devices in the field, handling a failed update, and patching CVEs after release are separate problems you solve yourself or by integrating tools like Mender or SWUpdate. With obligations like the EU Cyber Resilience Act, knowing exactly what’s deployed on each device stops being optional.

The Thymis approach: image building + fleet management in one

Thymis builds on NixOS and its functional package manager. Instead of imperatively scripting how an image is built, you declare what should be true on the device; the same definition produces a reproducible image and manages the device over its lifecycle:

Define a configuration or upload your software: through the web interface, or by writing Nix modules if you want lower-level control
Get a reproducible image: for Raspberry Pi and other ARM/x86 targets, reproducible bit-for-bit from the same inputs
Operate the fleet: OTA updates, automatic rollback on a failed update, remote access, monitoring, and a VNC device view

Reproducibility here isn’t a CI discipline you have to enforce; it’s a property of the model. The same inputs produce the same image.

Yocto vs. Thymis at a glance

	Yocto	Thymis
Onboarding	Weeks to months (BitBake, layers, recipes)	Hours: web UI, declarative configuration
Image creation	Your own build infrastructure, hours per build	Automatic, generated by Thymis
Reproducibility	Possible, but hard to guarantee	Built in via NixOS
OTA updates	Not included (add Mender, SWUpdate, …)	Built in, one action for the whole fleet
Rollback	Yours to implement	Automatic on failed updates
Fleet management	Not included	Dashboard, tags, inheritance, mass deployment
Best for	Embedded Linux specialists	Product teams that want to ship software
License	Open source	Open source (AGPL), cloud & enterprise optional

When Yocto is still the right choice

This isn’t a tool-as-religion argument. If you’re bringing up exotic hardware with a custom BSP, need to control every byte of the root filesystem, or already have a dedicated embedded team fluent in BitBake, Yocto is a proven choice and worth keeping. A NixOS-based workflow makes more sense when you’re on standard hardware (Raspberry Pi, x86 gateways) and time-to-market, maintainability, and a safe update path matter more than maximum customizability.

Migrating from Yocto to Thymis

A low-risk path is incremental rather than a big-bang cutover: start with one pilot device, define your application as a module (containerized is usually the lowest-friction first step), and run the generated image alongside the existing fleet until you trust it. Because each device’s state is a declarative config, you can diff exactly what differs between old and new instead of guessing, which also gives you the per-device traceability auditors look for.

Frequently asked questions

Do I need to know NixOS to use Thymis?

No, not to get started. Thymis sits in front of NixOS with a web interface and ready-made modules, so the first image comes from a configuration, not from writing Nix. When you need custom behavior, you can drop down and write a Nix module; it’s available, not required.

Which hardware is supported?

Common platforms such as Raspberry Pi, plus other ARM and x86 targets. See the documentation for the current list.

How much does Thymis cost?

The open-source version is free to self-host on up to 5 devices. Cloud plans start at €30/month if you’d rather not run the server yourself. See pricing.

Is Thymis also a Buildroot alternative?

Largely, yes. Buildroot is leaner and friendlier than Yocto, but it still leaves updates and fleet management entirely to you, so the same trade-off applies.

Trying it out

If the build-system overhead above sounds familiar, the open-source version is free to self-host on up to five devices, so it’s straightforward to evaluate against your current setup.

Get started · View on GitHub · Read the docs

Yocto Project and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation.

Yocto Alternative: Embedded Linux Without the Build Pain