How Many Arm UBL Seats Do You Actually Need?: A Sizing Guide for Indian CI/CD Teams

The single most-asked question from Indian engineering managers during the FlexNet Node-Locked → UBL migration is also the one that doesn’t have a generic answer: “how many UBL seats do we actually need?” It depends on how your team is shaped, and it is almost always close to your developer-and-bot headcount, not to your FlexLM seat count and not to your peak parallel-build count.

This post explains the framing. The actual sizing exercise, the per-team identity audit, the CI-topology review, the headroom decision, is the conversation GSAS Micro Systems runs with you during the UBL migration.

GSAS is Arm’s authorized partner in India for Arm Development Tools. We do the UBL sizing engagement before you renew, regardless of whether you are buying MDK Essential, MDK Professional, AC6 standalone, or AC6 FuSa. (ATfE Professional is sold direct by Arm.)

The framing: UBL is licensed per user identity

Per Arm’s published User-Based Licensing administration documentation on developer.arm.com, UBL is licensed against a user identity, not against a machine and not against a concurrent-build count. The model differs from FlexLM in three ways that change the sizing math:

1. A developer with multiple machines is one seat. Their identity can move between an office laptop, a home workstation, and a hot-desk in another city.
2. An offline cache window covers travel and on-site visits. Per Arm’s UBL technical documentation, the local armlm cache renews when the machine is online; refer to Arm’s published cache-lifetime guidance for the current operational window.
3. A CI bot identity covers parallel builds. A single Jenkins / GitHub Actions / GitLab runner identity that runs many parallel jobs is one seat, not one seat per parallel job.

The practical implication: sizing UBL against the FlexLM intuition (one seat per concurrent compile) consistently over-buys. The right anchor is the number of distinct identities compiling Arm code, with a small headroom decision GSAS walks through.

Why the sizing exercise needs a conversation, not a calculator

Two structural reasons:

• Identity topology is team-specific. A team running one Jenkins bot is shaped differently from a team running per-business-unit CI pipelines, and different again from a team with a separate air-gapped LLS bot for safety builds. The identity count is not derivable from headcount; it needs a brief walk-through of how the CI estate is configured.
• Indian procurement decisions sit alongside the migration plan. UBL adoption usually accompanies a csolution.yml modernisation, a Keil Studio Desktop pilot, or a CI rebuild, and the sizing decision benefits from being made in that wider context. GSAS keeps the procurement and engineering conversations in one room.

The sizing exercise itself takes about 30 minutes. We come out of it with a seat number you can stand behind to your Indian procurement team, and a CI-identity map that survives the next two renewal cycles.

What we do in the UBL engagement

• Pre-quote sizing call: a single 30-minute working session, anchored on Arm’s actual UBL identity model rather than the FlexLM intuition.
• CI identity review: we look at your CI configuration and decide whether you have one identity, a small number, or a larger fleet across business units.
• LLS deployment for air-gapped programmes: for Indian defence and aerospace customers, we run the on-prem Local License Server (LLS) setup and the network-policy review with your IT-security team. The seat-sizing math is identical to the default Cloud License Server (CLS) path; only the deployment model changes.
• Renewal-cycle reviews: we re-run the audit ahead of each renewal so the seat count stays honest as the team grows or contracts.

Edge cases we cover in the engagement

A short list of questions that come up in most Indian-team conversations, each one is a sizing-impact decision GSAS walks you through during the pre-quote call:

• Offshore developers in Singapore, US, or Europe.
• Contractors and consultants who build firmware under their own identity.
• Mixed-SKU teams (some on MDK Essential, some on MDK Professional, some on standalone AC6 FuSa).
• Air-gapped LLS deployments for Indian defence and aerospace customers.
• Mid-renewal headcount changes and seat-count adjustments.
• Multiple distinct CI systems (e.g. Jenkins for the firmware monorepo plus a separate GitHub Actions runner for the bootloader repo), each one is its own identity.

There isn’t a generic formula for any of these, each maps differently against the UBL identity model, and the right answer for your team is the one we walk through together. See Arm’s published UBL administration documentation for the underlying rules.

What to do this quarter

If you are on FL-NL today and planning the UBL migration:

1. Pull the rough headcount of developers, contractors, and CI bot identities that build Arm code.
2. Note any business-unit splits in your CI configuration.
3. Talk to GSAS, we run the sizing exercise with you in 30 minutes and produce the seat number you take into procurement.

The number is usually lower than the equivalent FlexLM footprint, sometimes substantially so. Getting it right is the single biggest UBL-quote saving available to Indian engineering managers, and it is the one place where Arm’s published rules differ from the FlexLM-era intuition most teams still carry.

GSAS Micro Systems is Arm’s authorized partner in India for Arm Development Tools, across Bengaluru, Hyderabad, Chennai, Pune, Mumbai, Delhi NCR, and Visakhapatnam.