We're getting an upgrade… literally! This blog covers what unsupported versions are, how these are managed via Scheduled Maintenances and what to expect during these upgrades.
We are slowly phasing out unsupported RabbitMQ versions below 3.13.x. This means we will be creating scheduled maintenance to upgrade clusters over the next few months. We will be notifying customers well in advance before running the upgrades so there will be ample time to contact our support team for any assistance required.
What is an unsupported upgrade?
Unsupported versions are listed by the RabbitMQ core team as versions that will no longer receive patches or support. Using the latest RabbitMQ versions are encouraged as they will contain fixes to bugs from older versions and more features. Over the years, CloudAMQP has supported a wide range of RabbitMQ versions and generally provides some unsupported versions. However, we've decided it's time to phase out some very outdated versions.
In the second half of 2025, the lowest available version for cluster creation will be the latest 3.13.x version. Please note that later versions can have breaking changes when moving to version 4.x and may require some actions to migrate. For more information on this, check out our blogs series about this here.
An important thing to note is that it is not possible to downgrade versions. If you require to stay on a specific unsupported version, please contact CloudAMQP support.
About Scheduled Maintenances (how to run or reschedule)
Scheduled maintenance are created and managed by the CloudAMQP team to keep servers up to date. There is a scheduled window set to run the maintenance and a Required By date for when customers can reschedule the maintenance before this time. Please note that times are in UTC.
Customers can view details of the upcoming upgrades via the Scheduled Maintenance tab in the CloudAMQP Console. This is where maintenance can be rescheduled or triggered to run early. Contact the CloudAMQP Support team if you need to reschedule outside of the allocated time and we can adjust this to suit customer needs.
Customers have the ability to set a preferred time to run all scheduled maintenance specific to each instance. Please refer to our blog about this here.
We recommend that customers update their Notice Alarm settings with the correct notification recipients to stay informed about upcoming maintenance. The system sends alerts when maintenance is scheduled, one hour before it begins, and at the start of the maintenance. Please make sure your contact details are current to ensure you receive all notifications.
What to expect during upgrades
There are a couple of notable things about these upgrades:
- Depending on the server’s current RabbitMQ version, it may require multiple version upgrades to reach version 3.13.x.
- We expect these unsupported upgrades to take approximately 20 minutes to complete.
- Please note that any custom plugins installed will be disabled upon upgrading and customers will need to contact CloudAMQP support to have these re-installed.
- Customers running TLS v1.0 and v1.1 will also need to contact Support to have these enabled.
Expected Downtime
During an upgrade, it requires a restart of RabbitMQ. This means any connections attached will close and will need to reconnect. We recommend ensuring clients are able to handle reconnecting to brokers.
There is expected downtime during an upgrade when RabbitMQ restarts however this can depend on your cluster setup:
Single clusters
All single node upgrades will require a couple of minutes of downtime upon restart. This can take longer if there are a very large number of virtual hosts, queues, or messages in the queues at the time of restart.
Multinode clusters
Version upgrades from 3.9.x will be rolling upgrades, advantageous for multinode clusters. This means that upgrades will be handled in a rolling fashion so each node will be updated in turn and the cluster as a whole should remain accessible to clients.
We recommend ensuring that clients are pointing to the general cluster hostname (DNS load balancer) as opposed to individual nodes as that should ensure that any connection requests will resolve to an online server node.
Upgrade without downtime
If customers cannot afford downtime, we would recommend the blue-green deployment strategy. This entails creating a new instance with the desired RabbitMQ version and migrating clients over. In that case, if there are any issues customers are able to revert clients back to the previous instance.
- Create a new instance
- Export definitions from old instance (if on a dedicated instance)
- Import definitions to new instance (if on a dedicated instance)
- Point your publishers to the new instance
- Allow consumers to empty the queues on the old instance
- Move consumers to the new instance
- Finish up by deleting the old instance
Utilising RabbitMQ queue federation can efficiently assist with migrating to another instance without stopping all producers and consumers as it transfers messages with ease. Please refer to our documentation on this here. If downtime takes too long, please email CloudAMQP support.
Tips to ensure upgrades go smoothly:
- Keeping messages low, recommended under 1,000,000 msg to avoid long sync times.
- If customers have a specific time of day where clusters experience low traffic, we recommend rescheduling upgrades during these times.
- Ensure messages are persistent and on durable queues.
- Auto delete queues (queues that are marked AD) will be deleted during the update.
- Ensure Notice alarm recipients are able to receive notifications.
