v4.2 - SaaS¶
Preview Release Date: June 5, 2026
Production ETA: June 11, 2026
Upstream Kubernetes for Bare Metal and VMs¶
Simplified MKS Version Selection¶
Users can now specify the Kubernetes version in major.minor format (for example, 1.34) when creating or upgrading MKS clusters using rctl or TF Provider. The platform automatically resolves the request to the latest supported patch release (for example, 1.34.7) during provisioning.
Benefit
Simplifies cluster lifecycle management by automatically adopting the latest patch release within a Kubernetes minor version, reducing template maintenance and operational overhead.
This behavior aligns with managed Kubernetes services such as Amazon EKS. The UI continues to require the full major.minor.patch version format.
Amazon EKS¶
Combined Blueprint Updates with Managed Node Group Upgrades¶
Customers can now update cluster blueprints and perform managed node group upgrades (Kubernetes version and/or node image upgrades) as part of a single operation. Rafay automatically orchestrates the required workflow and execution order, eliminating the need to perform these changes sequentially.
Benefit
Reduces maintenance windows and operational complexity by enabling multiple cluster lifecycle changes to be executed in a single coordinated workflow.
Supported Scenarios
-
Blueprint + Kubernetes Upgrade
Update the cluster blueprint and upgrade the managed node group's Kubernetes version through a single operation. -
Blueprint + Node Image Upgrade
Apply a new blueprint version while simultaneously upgrading the underlying node image for managed node groups.
Delete Protection¶
Support has been added for Amazon EKS Delete Protection to help prevent accidental cluster deletion. When enabled, a cluster cannot be deleted until delete protection is explicitly disabled, providing an additional safeguard for production and mission-critical environments.
Benefit
Helps prevent accidental cluster removal and reduces the risk of service disruption by adding an extra layer of protection for critical environments.
Google GKE¶
GKE Release Channel Support¶
Rafay now supports Google Kubernetes Engine (GKE) Release Channels, allowing customers to select and manage the release channel for each cluster during provisioning and throughout the cluster lifecycle.
Benefit
Provides greater control over Kubernetes upgrade timing by allowing organizations to align GKE upgrades with internal testing, change management, and promotion processes.
GKE Release Channels determine the cadence at which Kubernetes versions and platform updates are made available and automatically applied to clusters. With this release, customers can configure the appropriate channel for each cluster based on their operational requirements and risk tolerance.
Customers can now: - Select a release channel during cluster creation (Day 0 operations) - Modify the release channel for existing clusters (Day 2 operations) - Align cluster upgrade schedules with internal governance and release processes - Prevent unexpected upgrades in production environments
Native MCP Server Support¶
AI-Powered Operations¶
Rafay now provides a native Model Context Protocol (MCP) Server that enables MCP-compatible AI assistants to interact with Rafay-managed infrastructure using natural language. Customers can deploy the MCP Server within their own environment and connect it to their preferred AI clients while maintaining existing security and governance controls.
Rafay MCP Server is integrated with Rafay's RBAC model and platform intelligence, ensuring AI assistants only access data and perform actions that the user is authorized to access.
Benefit
Enables secure, AI-assisted operations by combining natural language interactions with Rafay's RBAC controls, allowing teams to troubleshoot and manage multi-cluster environments more efficiently.
The MCP Server provides AI assistants with access to Rafay operational context across clusters, workloads, blueprints, and projects, helping users quickly identify issues, understand fleet-wide health, and troubleshoot deployments.
Example Queries¶
- Which clusters in my fleet are currently unhealthy?
- Summarize the health status of all clusters across projects.
- Identify failed blueprint deployments in the last 24 hours.
- Why is a specific workload or pod unhealthy?
- What recent deployment failures require attention?
- Which clusters are not compliant with the approved blueprint version?
!!! note “Availability” Download access for the MCP Server binary is currently controlled through a feature flag. Please contact Rafay Support to enable this capability for your organization.
Environment Manager¶
HPA Support for Function Workflow Handlers¶
Environment Manager now supports Horizontal Pod Autoscaling (HPA) for Function Workflow Handlers. Administrators can configure autoscaling policies based on CPU and memory values or utilization, allowing function handlers to automatically scale between configured minimum and maximum replica counts as workflow demand changes.
Benefit
Improves scalability and performance for workflow execution by automatically scaling function handlers based on demand
Function Workflow Handlers are designed to process large numbers of requests efficiently. With HPA enabled, the platform can dynamically add capacity as request volume increases.
Note: HPA support requires the latest agent version and must be explicitly enabled. Existing environment templates continue to operate without change.
GitOps¶
Agent Upgrades via non-UI interfaces¶
Rafay now supports GitOps agent upgrades through non-UI interfaces, including APIs, RCTL, Terraform Provider, and GitOps. Previously, GitOps agent upgrades could only be performed through the Rafay UI.
Benefit
Enables automated GitOps agent lifecycle management without relying on manual UI operations.
Workloads¶
Enhanced Support for Multiple Helm Values Files¶
Rafay now supports multiple Helm values files across both chart repositories and external override repositories. All referenced values files are processed and merged in the specified order during workload deployment.
Benefit
Enables flexible configuration management by allowing teams to separate application charts from environment-specific overrides while supporting layered Helm configurations across multiple repositories.
This enhancement supports the following deployment models:
- Helm chart and values files stored in the same Git repository
- Helm chart stored in one Git repository with values files stored in a separate override repository
- Helm chart stored in an Artifactory Helm repository with values files stored in an override Git repository
Customers can now define multiple values files from both the chart source and external override repositories, enabling reusable base configurations with environment-specific customization layers.
Previously, when multiple values files were referenced from an external repository, only the first values file was processed. This limitation has been removed, and all specified values files are now correctly merged and applied during deployment.
