Running Arm User-Based Licensing in Modern CI/CD Workflows

Modern embedded software development no longer ends at a successful local build. Firmware is now continuously compiled, tested, analyzed, and packaged through automated pipelines running on Jenkins, GitHub Actions, GitLab CI, Azure DevOps, and dedicated build servers. While these environments simplify software delivery, they also introduce a practical question for many engineering teams:

How should commercial embedded development tools be licensed within an automated build environment?

Unlike traditional node-locked licensing, Arm User-Based Licensing (UBL) associates the license with the operating system user executing the Arm development tools rather than a specific machine. This model fits naturally into modern CI/CD infrastructure where build servers, virtual machines, and cloud runners are regularly created, replaced, or scaled without requiring licensing to be tied to individual hardware.

A common deployment pattern is to provision a dedicated Windows build runner using a service account such as jenkins, builduser, or gitlab-runner. The UBL license is activated once under that operating system account, allowing every pipeline executed by the same user to access the licensed Arm Compiler or Keil MDK installation without requiring interactive activation during each build.

This separation between the CI platform and the licensing mechanism is important. GitHub Actions, Jenkins, or GitLab simply schedule the build; the Arm development tools validate the licensed operating system user at runtime. Once the environment has been provisioned, the licensing process becomes transparent to the pipeline itself, allowing engineering teams to focus on build automation rather than license management.

Containerized environments introduce another consideration. UBL identifies the effective operating system username inside the container rather than the Docker host. If a build container executes as root, the licensing system also identifies the user as root. For dedicated CI runners this is a supported deployment model, provided the license is activated for that shared build account. For developer-specific containers, Arm recommends using individual usernames so each engineer's license remains associated with their own environment rather than every user appearing as root.

Many engineering organizations also maintain products developed with older Arm and Keil toolchains while introducing modern CI practices. Rather than maintaining separate licensing strategies, Professional UBL licenses can generate compatible node-locked licenses for supported legacy tools including Arm Compiler 5, PK51, PK166, and DK251. Arm also provides unattended installation methods together with command-line licensing utilities, allowing legacy projects to be provisioned automatically as part of a build server image or virtual machine deployment instead of requiring manual IDE configuration.

As build infrastructure grows, another common question is whether every virtual machine requires its own license. In practice, the answer depends on how the build environment is deployed. Because UBL licenses the operating system user rather than the hardware, organizations commonly create dedicated build identities that can be reused across multiple build servers and virtual machines. For larger deployments, environments with restricted internet connectivity, or enterprise-scale infrastructure, Arm additionally supports Proxy Activation and Local License Server (LLS) workflows to simplify license management while reducing repetitive online activation requests.

For teams designing reproducible CI infrastructure, Arm also recommends automating the provisioning process. Installing the required toolchain version, activating the build account once, and scripting the remaining environment configuration allows new build runners to be deployed consistently across physical servers, virtual machines, or cloud-hosted infrastructure. This approach minimizes manual configuration while ensuring every runner behaves identically, an important requirement for deterministic embedded software builds.

User-Based Licensing is ultimately designed to complement modern embedded software development practices rather than constrain them. Whether firmware is being compiled on a local build server, a virtual machine, or a cloud-hosted CI runner, UBL provides a licensing model that aligns with automated software delivery while remaining compatible with both current Arm development tools and many existing legacy projects. As engineering organizations continue investing in DevOps and continuous integration, licensing becomes another component of the build infrastructure one that can be provisioned, automated, and managed alongside the rest of the development environment rather than treated as a separate administrative task.

If you'd like to explore specific deployment scenarios in greater detail, Arm provides several excellent technical articles covering User-Based Licensing in automated development environments.

Further Reading from Arm Documentation:

• Legacy Keil tools installation and automating UBL registration for CI environments (GitHub Actions, GitLab Runners, and build servers)
  

• Running Keil MDK build tools in Windows Docker containers, including supported configurations, limitations, and licensing considerations
  

• Understanding User-Based Licensing (UBL) behavior in Docker containers running as root, including licensing implications and recommended deployment practices
  
  

If you'd like to discuss your CI/CD environment, migration strategy, or User-Based Licensing deployment, feel free to reach out Hrutik Champaneri at hrutik.champaneri@joraltechnologies.com