Upgrades and Maintenance
As a fully-managed service, the Redpanda Cloud control plane handles all maintenance operations, such as upgrades to your software and infrastructure. Here, control plane refers to the Redpanda Cloud managed service that orchestrates cluster operations, not the Kubernetes control plane.
For BYOC and Dedicated deployments, Redpanda manages all maintenance operations for the underlying infrastructure and Kubernetes, ensuring high availability. This includes Kubernetes version upgrades (both the Kubernetes control plane and worker nodes), security patches, and VM image updates. You do not need to act on Kubernetes end-of-life or deprecation notices from your cloud provider (for example, EKS, GKE, or AKS version warnings). Redpanda handles these upgrades on your behalf, targeting completion before the Kubernetes version reaches end of life.
For Serverless deployments, Redpanda manages all maintenance centrally because Serverless clusters run on shared, multi-tenant infrastructure. You cannot configure a maintenance window or per-cluster schedule for a Serverless cluster. See Serverless maintenance.
Redpanda runs maintenance operations on clusters in a rolling fashion, accompanied by a series of health checks, so there is no disruption to the availability of your service. As part of the Kafka protocol, recycling nodes triggers client connections to be restarted. All mainstream client libraries support automatic reconnections when a restart occurs.
After reading this page, you will be able to:
-
Compare minor upgrades, major upgrades, and deprecations and what to expect from each
-
Explain how scheduled maintenance windows and tier migrations work for BYOC and Dedicated clusters
-
Distinguish maintenance behavior for Serverless versus BYOC and Dedicated clusters
Maintenance windows
Maintenance windows are available for BYOC and Dedicated clusters.
For BYOC and Dedicated clusters, Redpanda Cloud may run maintenance operations on any day, at any time. You can override this default and schedule a specific maintenance window on your cluster’s Dataplane settings page.
If you select a Scheduled maintenance window, then Redpanda Cloud runs operations on the day and time specified. Maintenance windows typically take six hours. All operations begin during your maintenance window, but some operations may complete after the window closes. All times are in Coordinated Universal Time (UTC).
| Redpanda Cloud maintenance cycles always start on Tuesdays. Clusters scheduled for maintenance on Tuesdays are updated first, and clusters scheduled on Mondays are updated last. Keep this in mind when sequencing updates for multiple clusters. |
Tier migrations
You can move a BYOC or Dedicated cluster to a different usage tier as your workload changes, for example to scale up before expected traffic growth, or to scale down after peak demand. For the tiers available to each cluster type, see BYOC tiers and regions and Dedicated tiers and regions. For BYOC clusters in organizations on usage-based billing, you can scale the cluster yourself, changing its broker count or machine type, from the Cloud UI, the Control Plane API, or the Redpanda Terraform provider. See Scale a BYOC Cluster. For Dedicated clusters, or if you want Redpanda to run the change for you, contact Redpanda Support. Redpanda runs the migration for you, and your maintenance window controls when it starts.
A tier migration changes the compute resources underlying your cluster while the cluster continues to serve traffic:
-
Redpanda provisions new brokers that match the target tier.
-
Partition data and leadership move to the new brokers in a rolling fashion, accompanied by health checks.
-
Redpanda decommissions and removes the original brokers.
Your cluster’s endpoints do not change. When Redpanda decommissions a broker, the broker’s client connections restart, and all mainstream Kafka client libraries reconnect automatically.
When Redpanda Support runs the migration for you, it begins during your Scheduled maintenance window, like other maintenance operations. If you have not selected a Scheduled window, Redpanda Cloud can start the migration on any day, at any time. A migration that starts in a maintenance window might complete after the window closes. Self-service scaling that you start from the Cloud UI, the Control Plane API, or Terraform does not wait for a maintenance window. It starts immediately. See Scale a BYOC Cluster.
If you manage your cluster with the Redpanda Terraform provider, update throughput_tier and redpanda_node_count in your configuration to match the new values after the migration completes. Otherwise, the next terraform apply reverts the change. See Scale a cluster.
|
Serverless maintenance
Serverless clusters run on shared, multi-tenant infrastructure, so Redpanda manages all maintenance centrally. You cannot configure a maintenance window, choose a maintenance day, or defer upgrades for an individual Serverless cluster. Redpanda may run maintenance operations on Serverless clusters at any time. Operations run in a rolling fashion across the underlying infrastructure and are designed to minimize workload impact. As with BYOC and Dedicated, all mainstream Kafka client libraries support automatic reconnections when a restart occurs.
Minor upgrades
During your defined maintenance window, Redpanda Cloud runs minor upgrades. Minor upgrades include standard Redpanda state changes that clients handle gracefully, such as leader elections.
| Category | Details |
|---|---|
Impact |
Minimal. |
Examples |
|
Frequency |
Minor upgrades could happen multiple times a day. |
Communication |
Prior communication happens only if necessary. There could be email notifications, updated documentation, release notes, or communication from your Redpanda account team. |
Timing |
At Redpanda’s discretion during your defined maintenance window. |
Major upgrades
Major upgrades may require code changes to customer applications, such as Kafka clients or API integrations.
| Category | Details |
|---|---|
Impact |
Potentially large. |
Examples |
|
Frequency |
Rare. |
Communication |
Email notifications may be sent to registered users with details about the change and available options. There could be updated documentation, release notes, and communication from your Redpanda account team. |
Timing |
Major upgrades may be coordinated with customers, but the final date set by Redpanda is not negotiable. |
Deprecations
Deprecations indicate future removal of features that you can currently use. There is no guarantee of equivalent functionality in new versions. Deprecations could be included in major upgrades.
| Category | Details |
|---|---|
Impact |
Potentially large, if you depend on the feature being deprecated. |
Examples |
|
Frequency |
Rare. |
Communication |
Email notifications may be sent to registered users with details about the change and available alternatives. There could be updated documentation, release notes, and communication from your Redpanda account team. |
Timing |
At Redpanda’s discretion. |
See also: Cloud API Deprecation Policy
Deprecated features
| Deprecated in | Feature | Details |
|---|---|---|
November 2025 |
Subset of TLS v1.2 cipher suites |
The following TLSv1.2 cipher suites will no longer be used for managed services such as Schema Registry, HTTP Proxy, and Kafka API:
See also: Cloud API Deprecation Policy |
May 2025 |
Cloud API beta versions |
The Cloud Control Plane API versions v1beta1 and v1beta2, and Data Plane API versions v1alpha1 and v1alpha2 are deprecated. These Cloud API versions will be removed in a future release and are not recommended for use. The deprecation timeline is:
See the Cloud API Deprecation Policy for more information. |
March 2025 |
Serverless Standard |
For a better customer experience, the Serverless Standard and Serverless Pro products merged into a single offering. Serverless Standard is deprecated. All existing Serverless Standard clusters will be migrated to the new Serverless platform (with higher usage limits, 99.9% SLA, and additional regions) on August 31, 2025. Retirement date: August 30, 2025 |
February 2025 |
Private Service Connect v1 |
The Redpanda GCP Private Service Connect v2 service provides the ability to allow requests from Private Service Connect endpoints to stay within the same availability zone, avoiding additional networking costs. To check the version of your Private Service Connect attachment, run:
The attachment name should show the suffix |
