Feb
v3.1-38 Patch 2¶
13 Mar, 2026
A patch release for v3.1-38 carrying critical bug fixes. Customers are recommended to deploy/upgrade to this version instead of v3.1-38.
Bare Metal as a Service (Non-BCM)¶
User Defined Password Support¶
A new user_password field has been added for Non-BCM bare metal instance provisioning, giving end users control over the OS-level password set on their provisioned servers. The behavior is governed by the generate_password flag on the compute profile:
generate_password |
Behavior |
|---|---|
false |
The user must supply their own password via the user_password field. |
true |
The platform auto-generates the password; the user_password field is ignored. |
v3.1-38¶
16 Feb, 2026
Token Factory¶
With this release, customers now have access to Rafay's Token Factory (aka Serverless Inferencing) offering. This enables service providers and enterprises to launch and operate a Token Cloud providing end users with an "OpenAI API" experience.
Info
Learn more about this new feature.
Inventory Management - VM SKUs¶
Bulk Node Onboarding¶
During node onboarding for VM SKUs, the Rafay platform prepares the node so it can be centrally managed and used for VM workloads. The high level steps are as follows:
Rafay's automated onboarding ensures that the hardware is tuned and optimized for peak performance and integrated seamlessly into the platform.
Step 1: Verification & Access
Secure Handshake: A secure, encrypted SSH tunnel is established to manage the configuration without exposing data.
Eligibility Check: Verify that the hardware meets the minimum specifications to run high-performance workloads safely.
Step 2: Environment Provisioning
OS Optimization: Confirm the Ubuntu environment is healthy and apply the latest security patches if required.
Core Stack Deployment: Automatically install the virtualization engine, networking drivers, and storage utilities required to host virtual machines.
Step 3: Hardware Introspection
Fingerprint the server to ensure that it can be optimally used:
PCI Mapping: Identify high-speed NICs and USB controllers for direct-assignment capabilities.
Performance Topology: Map the NUMA nodes (CPU and Memory layout) to ensure your applications run with the lowest possible latency.
GPU Acceleration: Detect and initialize any available GPUs for AI, ML, or rendering workloads.
Step 4: Final Certification
Run a final suite of tests confirms the environment is stable. The device is marked as vmaas-onboarded. You will now see this node as "Active" and "Ready" in your management dashboard.
With this release, admins can now use the bulk node onboarding workflow to provide multiple bare metal servers to the Inventory at the same time. This allows admins to onboard 10s or 100s of servers at the same time enabling providers to add capacity quickly and efficiently.
Step 1
Click on bulk node onboarding to initiate the workflow
Step 2
Create a new onboarding trigger.
Step 3
Specify name and batch size.
Step 4
Node onboarding can take several minutes for every node. Bulk node onboarding is performed in parallel saving significant time for admins. They can monitor status/progress
Onboarding History
Admins are also provided with a view into details for historic runs. They can filter by "status" or "date" or "search" by name.
Inventory Management - Kubernetes based SKUs¶
Inventory now supports automatic synchronization of Kubernetes nodes using a platform-recognized node-level label.
When nodes are labeled with paas.envmgmt.io/node-sync=true, the Rafay operator on the k8s cluster will automatically keep the Inventory in-sync with hardware details such as CPU, memory, storage, and GPU configuration. The sync operation is performed automatically every 120 seconds by the Rafay k8s operator on the host k8s cluster.
Info
This enhancement supports Pod-as-a-Service and GPU-based SKUs, including fractional GPUs using NVIDIA MIG, and ensures that inventory records remain continuously updated as node characteristics change.
SKU Management: Sharing and Visibility Controls¶
SKU Management has been significant enhanced in this release to provide additional controls to manage how SKUs are shared with tenant organizations and projects, and how SKU visibility is handled at a per-tenant level.
Sharing Behavior
| Org Scope | Auto-share | Behavior |
|---|---|---|
| All Orgs | True | SKU is shared with all tenant orgs and all projects within each org |
| All | False | SKU is shared with all tenant orgs, but not automatically shared with their projects. Tenant admins control project-level sharing. |
| Org-X | True | SKU is shared with Org-X and all projects in the Org |
| Org-Y | False | SKU is shared with Org-Y, but not automatically shared with projects |
SKU Sharing with Projects¶
When Operators share SKUs with specific tenant Orgs, they can now control whether the SKUs should be automatically shared with "all projects" in the tenant orgs or not. When the SKU is shared with a tenant org, the admin is now provided an option to Share with All Projects.
In the example below, the SKU is shared with the Coke Org, but it is not automatically shared with "All Projects".
This means end users in the Coke Org will not automatically be able to consume the SKU until the Tenant Admin for the Coke Org explicitly shares the SKU with specific projects.
When Operators share a SKU with a tenant Org, they can also select the option to "Share with All Projects". When this option is selected, in the Coke Org, the tenant admin can see that the SKU in their Org is "already shared" with all projects. This means all users will now be able to consume the SKUs.
Org Exceptions for SKU Sharing¶
When sharing a SKU with "All Orgs", providers can now specify "exceptions" for Orgs. The SKU will not be automatically shared with the selected org exceptions.
Share SKU with All Projects¶
When sharing a SKU with "All Orgs", providers can now ensure that the SKU is made available to users in "All Projects" in customer tenant Orgs.
Per-Tenant SKU Visibility Control¶
Per-SKU, per-tenant configuration allows disabling a SKU for specific tenant organizations. When disabled, the SKU is hidden from the selected tenant organization and cannot be used for new instances.
Info
Existing instances created using the SKU are not impacted and remain available.
System Variables¶
For certain scenarios, specific variables may need to be overridden through global settings (e.g. each tenant gets a dedicated cluster on which their applications are deployed). To support this, variables can be marked as system variables in a SKU/Profile in the SKU Studio.
In the example below, for "input1", the "system variable" flag is enabled. Although this not visible to end users in tenant orgs, this value can be "dynamically overriden" via Global Settings.
Info
System variables are visible only within the Default Org and are never exposed to tenant customers, ensuring a clean and consistent tenant experience.
Centralized Blueprint Management¶
Blueprints enable assembling the required set of add-ons and applications (for example, GPU Operator and security software) that are installed during Kubernetes cluster provisioning. Previously, a cluster blueprint had to be created within each tenant Org where a cluster was provisioned.
With this release, operators can create cluster blueprints in their "Default Org" and reference or consume them when provisioning clusters in tenant Orgs. This allows them to centrally manage and version control cluster blueprints and leverage them in 100s or 1000s of tenant orgs.
For more details, refer to this page
End User Usage Dashboard¶
Similar to the tenant-level usage dashboard previously introduced for the tenant admin persona, this release adds an end-user usage dashboard.
Upon logging in, users can view a bird’s-eye summary of usage information based on their access, including:
- Number of workspaces
- Number of instances
- GPUs and CPUs allocated to instances
- An aggregated view of current resource utilization
This dashboard enables users to further drill down into specific details and take relevant actions as needed.
Ops Console Improvements¶
The following enhancements have been introduced in this release:
User Password¶
During organization creation, setting a user password is no longer required when SMTP is already configured on the Rafay Control Plane/controller. The user will be sent a temporary password to their email address and will need to use it to reset their password to their Org.
SMTP Configuration¶
In addition to the declarative YAML spec based approach that is already supported, SMTP configuration for the Rafay Control Plane can now be performed via the Ops Console.
User LCM Audit Logs¶
Audit logging has been enhanced for User Lifecycle Management (LCM) operations to improve visibility across partner and organization contexts.
Audit logs are generated for key user-initiated administrative actions and include partner and organization association, structured audit records stored in JSON format with expandable details, and filter support by operation type, user, client, and time range.
For more details, see User LCM Audits.
Resource-Level Deployment Status Messages¶
Compute and service instances now support resource-level deployment status messages sourced from annotations configured in resource templates. These annotations are defined per resource and are evaluated during instance deployment. When configured, the corresponding custom message is displayed on the instance page based on the current deployment state of each resource.
If no custom annotations are configured, the system continues to display the default environment-generated message.
Supported deployment states include In Progress, Success, Failed, and Waiting for Approval.
For more information, refer to Deployment Status Messages.
Internationalization & Localization¶
The end user facing self service portal can now be localized to support different languages via language resource bundle files provided via the Ops Console.
Default Languages¶
English, Turkish, Japanese localization is supported by default.
Default Locale¶
Admins can specify the default locale for all users spanning all tenant orgs. The user will be presented with the language from the configured default locale.
Enable Language Selection¶
Admins can enable/disable language selection for users. When enabled, users will be provided the option to select from a list of available languages.
Administration¶
Admins can select/configure "language customizations" section as shown below.
Shown below is an example of the administrator adding language customizations for "Mandarin"
Info
In the same Rafay Controller, different languages can be supported for different partners. For example, Partner-Alpha may support English and Turkish. Partner-Beta may support Japanese and Turkish.
End User Experience¶
End users can select their preferred language when they login into the self service portal. Shown below is an example when the user selects Japanese as their preferred language in the login page.
Once the user logs in, the self service portal is shown using the Japanese language customizations.
The user is also shown the selected language customizations when they try to launch/consume SKUs. In the example below, the user has selected "Turkish" as their preferred language.
Info
As of this release, we support only left-to-right languages, with additional language support planned for the future.
For more details, refer to this page