Kvaser Edge under the hood: Key answers for customer conversations

In this CTO Q&A, we take a dive into the architecture behind Kvaser Edge, answering key developer questions.

Q: How much control do developers really need over the OS, and what’s the cost of that control?

A: Full control is attractive in theory but in practice, it often means taking full responsibility. Once you own the entire OS stack, you also own every update, every dependency, and every failure scenario. What we’ve found is that most teams don’t need low-level control everywhere. With KEOS, the OS behind Kvaser Edge, we provide control at the application level, while keeping the system layer stable and managed.

Q: Why did you choose not to base the Kvaser Edge platform around a Yocto-first model?

A: Yocto gives you a lot of control, but it also comes with the operational cost of maintaining it. That means managing build environments, supporting developers, and troubleshooting issues that are often far removed from the actual application. Even experienced teams can struggle to keep those setups stable over time and in some cases, need to rely on external support just to produce builds consistently.

Instead of making Yocto the starting point, we chose a model where the system is ready to use from day one. You still have flexibility where it matters, but without the burden of maintaining the entire build system.

Q: Kvaser Edge uses standard Linux distributions in the application layer. Why was that important?

A: It comes down to usability and productivity. Developers already know standard Linux environments like Debian or Ubuntu – how to install packages, manage dependencies, and use familiar tools.

Within KEOS, that same familiarity carries across to the device. If you force developers into a custom distribution or toolchain, you slow everything down and introduce friction. Even something like installing Node.js becomes harder than it should be. By staying within a standard environment, we remove that friction and let developers work the way they’re used to.

Q: A common issue with embedded Linux is managing development environments. How did you approach that?

A: We wanted to avoid the classic “it works on my machine” problem. In many embedded setups, you need a specific SDK, toolchain, or build environment just to get started.

Our approach is to keep the development environment as close as possible to what runs on the device. That reduces differences between development, testing, and deployment, and makes setups much easier to reproduce.

Q: For teams that want to build custom images, what does that look like on Kvaser Edge?

A: We support that, but with a much lower barrier to entry. Instead of relying on complex embedded build systems, you can use standard Linux tools to create a custom image. That process is significantly faster and easier to work with (it takes minutes rather than tens of minutes on high-end machines). So, for teams that want full customization, it’s available, but it doesn’t require deep expertise in specialized build systems.

Q: How does the Kvaser Edge, with its separate system and application layers, compare to traditional image-based workflows?

A: With traditional image-based workflows, you often start with a base image and then layer applications and configuration on top. The challenge is that those layers aren’t always preserved during updates. If you install a new system image, such as a security patch, you may need to rebuild or reinstall everything on top of it, leading to scripting, manual steps, and potential failure points. Updates to the Kvaser Edge system don’t remove applications or configurations, making the lifecycle more predictable and stable.

Q: What is the role of containers or isolated environments in edge systems?

A: Containers, or container-like approaches, help ensure that applications run consistently and don’t interfere with each other, which is key to achieving reproducibility and stability. At the same time, users shouldn’t need to understand container infrastructure to benefit from it. Our goal is to provide those guarantees in a way that feels natural, using familiar tools and workflows.

Q: How do you ensure reproducibility of deployments across devices?

A: Reproducibility comes from controlling the full execution environment. Applications are packaged together with the dependencies they need, so the runtime environment is consistent. This eliminates the drift that you typically see when configurations are applied manually or systems evolve over time. For smaller setups, it means fewer surprises and at fleet scale, it means you can trust that every device behaves exactly like the one you tested.

Q: Updates are often where embedded systems become fragile. What design choices did you make around OTA?

A: We assumed from the start that updates will fail at some point. So instead of trying to prevent failure entirely, we focused on making failure safe. Updates are applied in the background and only activated once they’re verified. If something goes wrong, the system automatically rolls back to the last working version.

Just as importantly, applications and configurations are preserved across updates. You don’t end up in a situation where you have to rebuild the device after every system change, which is critical when you’re managing devices in the field.

Q: What mechanisms are in place to ensure devices remain recoverable in the field?

A: If an update fails, the system reverts automatically to a known working state. That avoids devices becoming unusable or requiring manual intervention. In addition, there’s always the option to restore the device to a clean baseline.

Q: How do you approach fleet-scale consistency?

A: You need to be able to trust that what you deploy is what actually runs. That means deployments need to be repeatable i.e. the same application setup that you test needs to run on every device in the fleet. Consistency is what makes large-scale deployments manageable.

Q: If a team is currently managing their own Yocto builds, when does it start to make sense to move away from that?

A: Usually when the overhead becomes visible. That might be the time spent maintaining build environments, onboarding new developers, or supporting customers who can’t reproduce builds themselves. At that point, the value of full control often no longer justifies the effort required to maintain it.

Moving to a platform that takes responsibility for the system layer can free up significant time and allow teams to focus on what differentiates their solution.

Tobias Stalfors, CTO of Kvaser