Important

This page will be periodically updated with features that are scheduled to roll into Rafay's Preview environment as part of upcoming releases. Learn more about Previews. Learn about our recent releases.

Navigate to our public roadmap for details on what we are working on for future releases.

v3.5 - SaaS¶

26^th May, 2025 for Preview Orgs

Blogs for New Features in Release¶

#	Description
1	k8s 1.33 for Rafay MKS
2	Revamped UI
3	Draft Versions for Blueprints

Revamped UI/UX¶

The Rafay Console UI has been revamped to provide administrators and end users with an improved user experience.

Info

Please read our blog for more insights into the rationale behind the revamped UI/UX.

Upstream Kubernetes for Bare Metal and VMs¶

Kubernetes v1.33 Support¶

Support is being added for Kubernetes v1.33 for Rafay's Kubernetes distribution. This includes: - Provisioning of new clusters with v1.33 - Upgrading existing clusters from earlier versions to v1.33

1.33 k8s version

Note

For more details on Kubernetes v1.33 support in Rafay MKS, refer to our blog post.

CNCF Conformance¶

Upstream Kubernetes clusters based on Kubernetes v1.33 (similar to prior Kubernetes versions) will be fully CNCF conformant.

Platform Version Support for Core Components¶

This release introduces Platform Versioning, starting with version v1.0.0.It enables upgrade management of core components in upstream Kubernetes clusters. Platform version v1.0.0 includes the following component versions:

CRI: v2.0.4
etcd: v3.5.21
Salt Minion: v3006.9

Upgrade Guidance¶

New clusters will be provisioned with this v1.0.0 platform version by default
Existing clusters can upgrade to this platform version either:
Independently
Along with Kubernetes upgrades
Platform versioning gives users control to manage critical component upgrades and respond to vulnerabilities

Note

For existing clusters, the initial platform version will be shown as v0.1.0, which is assigned for reference purposes to older clusters that were created before platform versioning was introduced. Please perform the upgrade to v1.0.0 during scheduled downtime, as it involves updates to core components such as etcd and CRI.

We will continue releasing updated platform versions as component-level enhancements or security fixes are made available.

Platform Version Display During Kubernetes Upgrade¶

Part of K8s Upgraed

Individual Platform Version Upgrade Option¶

Individual Upgrade

OS Field Update Capability in Cluster Configurations¶

Previously, the OS field in the cluster configuration was immutable once the cluster was provisioned. This posed challenges in cases where the underlying operating system on the nodes was updated out-of-band (outside Rafay).

With this enhancement, users can now manually update the OS field in the deployed configuration file. This ensures that the configuration stays in sync with the actual state of the nodes, improving operational visibility during Day 2 operations.

RCTL Cluster Upgrade Response Enhancement¶

Enhancements have been made to the RCTL response during cluster upgrades. The response now includes both the source version and target version of the upgrade.

This enhancement improves user experience by clearly showing the current and target Kubernetes versions during upgrades, making the process more transparent and traceable.

Sample Response¶

Dry Run:

{
  "operations": [
    {
      "operationName": "ClusterUpgrade",
      "resourceName": "test-consul-rocky"
    }
  ],
  "comments": "Cluster will be upgraded from  v1.31.4 to v1.32.0"
}

Display of CNI Add-on Version in System Blueprints¶

System blueprints will display the version of the CNI add-on in the UI. Previously, this information was not visible making it unclear which CNI version would be applied by the default CNI system blueprint.

This enhancement improves transparency and user experience by providing clear visibility into the CNI version being deployed.

CNI Version

Azure AKS¶

In this release, support has been added for Kubernetes versions 1.31 and 1.32, including both new cluster provisioning and upgrade workflows.

Version 1.31 Support¶

1.31

Upgrade to Kubernetes Version 1.32¶

upgrade to 1.32

Version 1.32 Support¶

1.32

Google GKE¶

In this release, Kubernetes v1.32 is supported for both provisioning and upgrades, and v1.29 has been deprecated as it is no longer supported by Google GKE.

1.32

Amazon EKS¶

EKS Auto Support¶

As part of Rafay’s commitment to maintain parity with native AWS EKS capabilities, this release introduces support for EKS Auto.

Amazon EKS Auto Mode streamlines Kubernetes cluster management by automatically provisioning infrastructure, selecting optimal compute instances, dynamically scaling resources, continually optimizing compute for costs, patching operating systems (OS), and integrating with AWS security services.

By integrating support for EKS Auto, Rafay enables users to benefit from a simplified cluster creation experience with baked-in AWS best practices, enhanced operational efficiency, and reduced configuration overhead.

For more details, refer to the AWS EKS Auto blog post.

Combined Cluster Label & Upgrade Operations¶

Users can now combine cluster label updates with Nodegroup AMI upgrades or Kubernetes version upgrades as part of a single operation. Previously, these actions had to be performed in isolation. This enhancement streamlines upgrade workflows and reduces operational overhead by enabling users to batch changes into a unified process, improving efficiency during Day 2 operations.

Blueprint & Add-on Management¶

Support for Draft Versions¶

Previously, draft version support for Blueprints and Add-ons was available only via non-UI interfaces. This enhancement brings the same capability to the UI, allowing users to configure and visualize draft versions directly through the console.

Draft versions

Note

For more details on draft version support, refer to our blog post.

GitOps¶

System Sync¶

Commits made by the GitOps pipeline will now include the author’s email address as the Git username in commit metadata. Previously, commits would display the author as “Unknown”. This was often due to missing or unrecognized user metadata. With this change, the author's email is explicitly included, ensuring that commits always contain a meaningful and identifiable username.

This improves auditability and traceability of GitOps operations across all integrated Git providers.

Parallel execution of Pipeline Stages¶

By default, stages within a configured pipeline are executed sequentially. However, in many cases, these stages are independent and do not require sequential execution. This enhancement introduces support for parallel execution of such stages, allowing users to design workflows such as deploying multiple independent workloads that run simultaneously. This results in reduced overall deployment time and greater automation efficiency.

Centralized Agent Configuration¶

This enhancement introduces centralized management of agent configurations via the controller. Administrators can now centrally define the following settings:

CPU and Memory Limits
Number of Engine Agent Workers (Determines how many worker pods are launched for executing Environment Manager activities)
Concurrency Limit for CD Agent RPC Calls (Controls parallel fetches of artifacts from configured repositories)
Tolerations, Node Selectors, and Affinity Rules (Provides control over agent placement within the Kubernetes cluster)

Note

Support for agent configuration will initially be available only through non-UI interfaces. Support with UI interface will be introduced in a subsequent release.

Repositories¶

Configuration¶

Customers are strongly encouraged to configure their own agents even for publicly accessible repositories. If no agent is specified for internet-accessible endpoints, the controller’s hosted agents will be used by default (not recommended for production use). For production environments, configuring dedicated agents helps avoid issues such as rate limits imposed by registries like Docker Hub.

Repository

Env Manager¶

State unlock¶

Terraform uses a locking mechanism to prevent concurrent modifications that could corrupt the state file. However, locks may sometimes persist due to failed or canceled runs often caused by lost connections to the build agent or updates to the storage backend holding the state file.

This enhancement introduces support for manually unlocking Terraform state environments that use OpenTofu-based resource templates and a compatible backend. It should be used cautiously and only it is verified that the lock is no longer valid.

Draft versions

UI Console Changes¶

Revamped UI for the Infrastructure Portal¶

A refreshed look and feel is being introduced to the Infrastructure Portal, focusing on a cleaner, more modern design. The update delivers a more efficient use of screen space, enhanced readability, and improved overall usability.

Note

For more details on this enhancement, refer to our blog post.

Console UI

User Management¶

IDP Integration¶

Optimizations are being implemented to improve performance in scenarios where users are associated with 100 or more IDP groups.

System Template Catalog Updates¶

Use Case–Driven Experience¶

The System Template Catalog is being enhanced to provide a more intuitive, use case–driven experience, making it easier for end users to discover and apply relevant templates based on their specific needs.

Catalog UX

Enhancements to Existing Templates¶

The following system templates have been updated to support Kubernetes versions 1.31.8 and 1.33:

system-mks
system-vsphere-mks

These updates ensure compatibility with the latest upstream Kubernetes versions and help streamline cluster provisioning workflows across supported environments.

Newly Added System Template¶

Namespace-as-a-Service¶

A new Namespace-as-a-Service system template is being added to the catalog. This template enables quick onboarding of isolated namespaces, complete with required security controls and policy configurations, making it easier to adopt secure multi-tenancy.

Approval Workflow Handlers¶

Support for workflow handlers is being added to the catalog to enable approval steps as part of the execution process. This ensures alignment with organizational policies by allowing integration with approval systems such as ServiceNow or JIRA before a workflow can proceed.