The numbers that bound a DataRobot subscription are not in its contract; they are in the product. DataRobot’s administrator documentation describes a licence page that shows licence details including the expiration date, the concurrent workers limit, the maximum active users, the prepaid deployment limit, the maximum deployment limit and, in some instances, subscription features, and says the details depend on the subscription.[1] This article follows those numbers in the order an administrator meets them: the licence key, seat licences, users and roles, workers and organizations, deployments, compute and usage reporting.
Editions
DataRobot documents features that depend on the licence rather than a published edition ladder. After a key is validated, the licence page lists the features and functionality included in the subscription for the administrator to confirm before submitting it.[2] Seat licences are described as a premium feature: they are only available to multi-tenant SaaS organizations that have a seat licence allocation, and to single-tenant SaaS or self-managed installations whose licence key has a cluster-level seat allocation that lets system administrators allocate seats to organizations; enablement is by contacting the DataRobot representative.[3] Multi-organization management is documented as available only in self-managed deployments.[4]
Applying and renewing a licence
Administrators apply a key from the profile icon, License page, by entering the key and selecting Validate, reviewing the listed features and selecting Submit; the same can be done with the REST API.[2] A valid, unexpired licence is required for model building on the self-managed platform. The application banner warns all users when the licence expires within 30 days by default, and a user can snooze the banner for four days at a time.[1] If the licence expires before a new one is applied, users keep access and can make predictions with existing models, but they cannot build new models or insights or generate Compliance Documentation; a running round of model building finishes, and everything resumes when the new licence is applied.[1] The documentation says a new key is requested from Support.[1]
Metrics
Seat licences and users
A seat licence grants a user access to specific functionality. Three kinds of account manage or use seats: the system administrator, who allocates seats across organizations in the installation (for DataRobot-managed deployments, the DataRobot team does this; for self-managed deployments, the customer’s system administrator does); the organization administrator, who assigns seats within an organization; and the user, who consumes an assigned seat.[3] A user account can only hold one role at a time, so the system and organization administrator roles need separate accounts.[3] Seats are allocated from Admin settings, License, Allocate seats, by naming the organization and the number of seats, and extra seats are added from the organization profile; assignment is by selecting a seat licence and the users, and seats are removed with Revoke seat.[3] The documentation notes that seat licences require specified feature flags to be enabled.[3] See Seat license.
Non-builder seats. Non-builder users can only interact with published applications, such as running predictions, adding prompts, starting chats and uploading data; they have no access to platform functionality or public APIs, and they do not count towards the maximum active user allocation.[3] If an organization has reached its maximum user allocation, a non-builder user cannot be created through the user creation flow; the administrator must either assign a non-builder seat to an existing user or invite a new user.[3] See Non-builder seat.
Roles and per-user limits. Role-based access control is additive, so a user’s permissions are the sum of those set at user and group level. On self-managed installations administrators can also set per-user limits: maximum personal worker allocation, RAM usage limit, file upload size limit and the Deployment page refresh rate.[3]
Workers
Workers are the processing power used to create projects, train models and make predictions, and DataRobot uses several types: DSS (Dataset Service) workers, EDA workers, secure modeling workers and quick workers. All workers except modeling workers are based on system and licence settings and are available to the installation’s users first come, first served.[5] For modeling, the administrator sets a total allocation and users may set per-project allocations up to their limit. Each user has four workers by default, a personal worker allocation that applies across all projects in the cluster; opening more browser windows does not add workers.[5] A project’s worker allocation stays with the project when shared, but every collaborator is still limited by their own personal allocation.[5] Changing a personal allocation does not affect existing projects.[5] The allocation of EDA workers is set by the system and neither administrators nor users can raise it.[5] See Personal worker allocation and Concurrent workers limit.
Organizations and groups
Organizations help administrators prevent resource contention by capping the total number of shared modeling workers available to their members. Every user belongs to one and only one organization. An organization of five users with ten workers can use at most ten workers together, since the allocation is not cascading, and a user with a personal allocation of four workers in an organization with ten workers can use no more than four.[5] The documentation says that the worker resource allocation is independent of the cluster configuration, and advises administrators not to oversubscribe the cluster’s physical capacity.[4] Groups let administrators manage users and project sharing; a user can belong to up to ten groups.[5] See Organization worker allocation.
Counting and floors
Deployments
For DataRobot MLOps, an administrator sets the maximum number of active deployments for an organization on its profile page under Max deployments, and the number cannot exceed the number listed under Prepaid deployments.[4] The deployment inventory shows active deployments against the limit and states that inactive deployments do not count toward the limit and do not support predictions, retraining, challengers or model replacement.[6] Deployments held in other organizations do not count against the limit of the current organization.[6] Not all limits are about numbers of deployments: administrators can also set maximum memory and maximum replicas for custom inference models, limit the number of custom model execution environments and versions a user can add (not above 999), and set notebook and codespace resource caps.[4] See Prepaid and maximum deployments.
Compute instances
For organizations using the serverless platform, the maximum compute instances can be adjusted on the organization profile under Max compute for a serverless platform; if no limit is specified, the maximum is 8.[4] See Serverless compute instances.
Virtualization and partitioning
The documentation expresses limits in workers, users, deployments and compute instances rather than processors, and treats worker allocation as independent of the underlying cluster.[4] The exception is the self-managed Usage Report, which charts CPU and GPU consumption over a chosen date range against the organization’s current licence limit for core usage and can be exported as CSV; it is only available to system administrators on self-managed installations.[7] A customer running DataRobot in a hypervisor or Kubernetes cluster should therefore compare its core usage with the licence limit rather than infer a limit from virtual machine counts, which the documents do not mention.
Cloud and BYOL
On SaaS, DataRobot’s team allocates seats to organizations.[3] The Usage explorer in Account settings shows GPU, CPU, LLM API, agentic span and storage usage by service for a date range and can be exported to CSV. LLM usage has two categories, LLM-DR hosted and LLM-BYOK (bring your own key); the first covers LLMs that DataRobot hosts and the second covers usage where the customer supplies its own provider key, and both reports are only available for single-tenant SaaS deployments.[8] The administrator Tenant usage explorer adds views by user, service or, on self-managed installations, organization.[7] See LLM API usage.
Programs
The limits above have no separate programs in the documents reviewed. The related commercial constructs are the Support and Maintenance terms, which DataRobot includes in the fees for the Solution,[9] and the evaluation program, in which Evaluation Software runs for 30 days.[9] The Deployment billing section of a deployment settings page notifies users of the number of deployments the organization is using against its limit and the deployment cost if the organization has exceeded the limit.[10]
Audits and compliance
DataRobot’s MSA has no audit clause, so the evidence is in these product pages. Practical review steps drawn from the documentation are: read the licence page for the expiration date, workers, active users and deployment limits;[1] compare seat allocations on the License page with assigned seats;[3] compare Max deployments with Prepaid deployments for each organization;[4] and export the Usage Report or Usage explorer for the period under review.[7][8]
Out of scope
This article does not cover the contents of any customer’s licence key, prices of seats or deployments, or the Installation and Configuration guide that DataRobot provides with a self-managed release, which the documentation names as the source for worker types.[5]