Prod vs dev images in Welma

Look at the differences between prod and dev images in Welma Yocto Linux.

In the life of a product and in software engineering in general, there are at least two major phases:

  1. Development (board bring-up, OS integration, application development),
  2. Production (in-line flashing, qualification, field deployment).

These phases come with radically different needs: speed and flexibility for development; security, compliance, and robustness for production.

That’s exactly why Welma natively provides two families of images: dev and prod, with the option of a test image when you need to validate “as close as possible” to real conditions without sacrificing observability.

Why separate prod vs dev images?

  • Convenience for dev teams: root access, debugging tools, interactive shell, SSH…
  • Security & compliance in production: hardening, locked-down permissions, minimal attack surface, proper license choices.
  • Manufacturing: sometimes an intermediate image is needed during assembly (bootloader open at first, then locked just before device close).
  • Quality: avoid last-minute behavioral differences; build and test a prod/staging image early to prevent surprises later.

What differs between a prod vs dev image in Welma

Note that the configurations below are default ones. Clients can adjust as needed, but Welma approach is clear: convenient for the development environment, secure for the production one.

1. Access rights

  • Dev: root access enabled; useful for loading/unloading drivers and quick system interventions.
  • Prod: no root access by default, no default password; anything that poses a cyber risk is disabled.

2. Packages & tooling

  • Dev: includes debugging tools (essential for application developers: debugger, analysis tools…) for efficient work.
  • Prod: removes these tools once they become unnecessary and risky (potential vulnerabilities); the image is not meant to be debugged in the field.

3. Licenses & compliance

  • Dev: more flexibility with tools, even if their license isn’t ideal for production.
  • Prod: restricts anything that could cause legal issues.

For instance, LGPLv3 requires allowing end users to modify the package. With Secure Boot, changing a package means resigning the image; to “allow” modification, you’d have to give away Secure Boot keys or build a complex partition structure.

Bash (command-line tool, script interpreter) is another concrete case: it is present in dev and in prod, we use dash to avoid license complications.

4. Security (secure boot & chain of trust)

  • Dev: Secure Boot may be disabled or enabled with limited constraints. For example, not closing the device: keys are present, but even if the signature is wrong, the system can still boot with an error message, avoiding the need to sign every test image.
  • Prod: the device is closed. Secure Boot will refuse to boot if the image isn’t correctly signed.

5. Bootloader (U-boot)

  • Dev: a dev bootloader can allow handy functions, like loading an alternate kernel via the command line (flexibility for testing).
  • Prod: a locked bootloader only loads the designated kernel, with no flexibility (and no option for other kernels).
  • Manufacturing: intermediate images can be used. They can start with a bootloader that helps load other images, then flash the locked bootloader when the device is fully closed.
prod vs dev images in welma yocto linux

An additional image for test

A test image can be useful for real-world testing without debug extras:

  • close to the production image, but with enhanced logs/traces, possibly a temporary technical user, and reinforced observability.
  • Th goal: minimize behavioral gaps between the test and the prod environment while keeping the ability to investigate issues quickly.

It’s important to avoid last-minute testing directly on the production image. Build the test/prod image early in the cycle so QA and validation happen under real execution conditions.

Naming & options in Welma

Welma provides reference images that follow this structure:

  • image-dev (or -dev),
  • image (prod).

They’re built with the right default options, aligned with the practices described above.

Conclusion

Separating prod vs dev images is a best practice: it speeds up software development, reduces production risks, and clarifies your manufacturing pipeline.
Read our article on development vs production images here. 

With Welma, you start with the right structure, useful features for dev, and safeguards (secure boot, verity, A/B partitioning…) for prod. Always keep a test/staging image in your cycle to avoid execution gaps between validation and deployment.

Contact us