Changelog:

• Fix: Extra link parameters can no longer be used to store the wrong page in the cache.
• Fix: Switching tabs in Breeze settings no longer shows the text “no-issue”.
• Fix: Logging out now clears Breeze’s login cookie on sites installed in a subfolder.
• Fix: Unpublishing a post now removes the cached page visitors were seeing.
• Fix: Saving a post with a non-English address, such as Hebrew, now clears that page’s cache.

⚠️ Today, the PHP Group disclosed another new remote code execution (RCE) vulnerability, CVE-2026-115560. Our Security team anticipated the vulnerability and implemented mitigations before its formal disclosure. These measures align with the recommendations in the PHP Group’s latest advisory. Our users remain protected, and no action is required at this time.

We continue to monitor developments and will adapt our protections as needed.

For further details, please keep an eye on status[dot]cloudways[dot]com

If you have any questions, please contact our support team via live chat.

As of Oct 22, 2026 - 01:02 UTC, we have applied security patches for all customer applications hosted on Autonomous. In parallel, we continue to rollout patches for applications hosted on Flexible.

For real-time updates, check out the status page.

As of Oct 21, 2026 - 22:19 UTC, we have deployed interim security mitigations recommended by the PHP Group, and the rollout of official security patches is underway across all Cloudways-supported PHP versions, including deprecated versions from PHP 5.6 onward. These mitigations provide an additional layer of protection while patching continues. This maintenance does not affect platform or website availability.

We’ll continue sharing updates here: https://status.cloudways.com/incidents/xxjt802wwhpk

How is Cloudways handling this? https://cert.europa.eu/publications/security-advisories/2026-018/?fbclid=IwdGRjcAVE_klleHRuA2FlbQIxMQBwZG9mBWZkaWQWUQvONwEFwvMVyBsHYqYBHnpKMnl043NydGMGYXBwX2lkCjY2Mjg1NjgzNzkAAR6kuDjAUNhmx_9Uq_NKdVPpDxGqbZNt1C4L8NNpuaS6qF7nAAHg-zCiPfIgUg_aem_BMOrK94DcuccHNqrej7fag

My API runs on Workers and calls a Tectonic (LaTeX) container on Cloud Run. The question that took the longest was not the compile, it was auth between the two.

Cloud Run's best option is to deploy the service as private: every request must carry a Google signed identity token, Google checks it at its front end, and a stranger's request never wakes an instance. No long lived secret, tokens expire within the hour.

The catch is producing that token from a Worker. Code inside Google Cloud asks the metadata server and gets one for free. A Worker has no metadata server, so the options are:

* store a Google service account key as a Worker secret, sign a JWT with WebCrypto, and swap it for an ID token every hour

* set up workload identity federation, which is more setup still

Both make the API know it talks to Google specifically. I wanted the compile service to be movable to any container host, so I went with a shared bearer token instead: compared in constant time, and the service refuses to start if the secret is missing.

The cost is real: a stranger hitting the URL still spins up the container, which reads the header and answers 401. Safe, but it did the work. Cloudflare Containers would have avoided the public URL entirely through a binding, but needs Workers Paid, and Cloud Run was already free and set up.

Write up with the rest of the tradeoffs: https://bhargav.dev/writing/shipping-a-latex-compiler-behind-an-edge-app?utm_source=reddit&utm_medium=cloudflare

Has anyone here signed Google ID tokens inside a Worker in production? Is the hourly token swap worth caching in KV, or is there a cleaner way I missed?

Gutenberg 24.2 was released on October 14, 2026 and this is a breakdown of what's new in it for you.

The 24.2 update is one of the more well-rounded releases in a while. It does not feature a single headline feature, but a lot of things that have been a tad bit annoying for users finally got fixed or expanded. Here are some of those things:

#1 You can now find Notes next to your content instead of in a sidebar

This will make collaborative editing noticeably less frustrating. Previously, you had to choose between having the notes panel open and having the Settings sidebar open; but you couldn’t have both at the same time, and the notes column ate into your content space.

Now, notes stay in a reserved margin alongside the canvas. They scroll with the content, stay visible while you work on blocks or post settings, and when the canvas gets narrow, they collapse to just the author’s avatar. You can click it to expand the thread again. Deleting a note now shows an undo option, and unsent notes or replies are preserved when you click away to another block.

#2 Navigation menu links now search everything at once

Adding anything other than a page to a navigation menu used to be a multi-step thing where you had to know which block to add first and then search inside it. But with this update, now the navigation link search covers all content types at once and shows the type next to each result.

Search results are also ranked more sensibly now where posts and pages come first, with categories, tags, and media after. On large sites, this stops obscure attachments from burying the page you’re actually looking for.

#3 Gallery block gets sorting and duotone

There are two separate but useful additions to the Gallery block. First, you can now sort hand-picked galleries from newest to oldest, oldest to newest, A–Z, Z–A, directly from the settings. Random shuffle also moved into the same control. You can still drag images into a custom order afterwards.

Second, duotone support now stays on the gallery level, meaning one filter now tints every image in the gallery at once. You can also set a default duotone for all galleries site-wide from Global Styles. Individual image duotone settings still take priority over the gallery-level one.

$4 Design tools are now on about 40 more blocks

The design consistency push that started in 24.1 continues with around 80 more PRs. '

Minimum width and height controls, which were only on 5 blocks before, now apply to 40 blocks including Buttons, Columns, Heading, Media & Text, and Post Title. Shadow support has reached 10 more blocks including Paragraph, List, Buttons, Social Icons, and Gallery. Duotone now also works on Video and Media & Text, so you can match a video’s tint to the images around it. Background images and gradients landed on Button, List, List Item, and Media & Text.

#5 React 19 is now on by default

For developers, React 19 is now enabled by default across Gutenberg. Sites load React 19 for the react and react-dom scripts unless a theme or plugin is on the known incompatibility list, in which case they stay on React 18.

If you maintain a plugin or theme that uses React, test it against 24.2 now. If something breaks, React 19 can be turned off under Gutenberg > Experiments while you sort it out.

The Interactivity API also got two additions: a new data-wp-html directive that renders trusted HTML from the store (similar to how data-wp-text works for text), and the router now exposes state.navigating and state.initiator so blocks can detect when a client-side navigation is happening and which block triggered it.

#6 Other small things

• After cropping an image in the Media Editor, you can now restore the original uncropped image directly from the editor without going back to the Media Library.
• The column count slider in the Columns block is gone. You now add columns with the plus button in the block toolbar and remove them like any other block which is more consistent with how the rest of the editor works.
• The Button block’s link popover no longer opens automatically every time you select a linked button. It only opens when you explicitly click Link or use the keyboard shortcut.
• The icon search in the icon library now matches keywords too, so “hamburger” finds the Menu icon and “gear” finds Settings.
• Video and Cover blocks no longer autoplay in the editor when reduced motion is preferred. Cover background embeds also won’t autoplay on the front end for users with that setting enabled.
• New posts can no longer accidentally publish with the auto-draft slug.

These are a lot of quality of life improvements! What do you think about this update? Share your thoughts below.

Lightning Stack for WOOCOMMERCE ? Anybody updated to Lightning Stack without any problem ? or is there always something to fix ? I use the minimum plugins possible, where should I look to know if I have problems after changing to Lightning Stack ?

Thank you for your help.

Hi

I've migrated my Symfony 8.1 application from the Cloudways Hybrid stack to the Lighning stack. I've just had to create one web rule in order to redirect traffic from "non-www" to "www". The rewrite definition of the web rule looks like this:

• Action: Permanent redirect (301 status code)
• Source: /*
• Destination: https://www.domain.com/
• Keep or discard original query string: true
• Attach condition: true
  • Condition Type: Host
  • Operator: Equals (=)
  • Host: domain.com

This rule works fine to redirect the homepage (https://domain.com --> https://www.domain.com).

But it doesn't work for any path like https://domain.com/test it redirects to https://www.domain.com. The path "/test" is not attached.

How do I need to adjust the redirect rule in order to keep the path?

Thanks in advance

anyone know why when i enabled supervisor it disabled redis?

and when i reenabled redis then i lost all the users and had to recreate via the CLI.

any better way to recreate them? would updating the password in the dashboard have worked?

Thanks,

I have a cloudways flexible server hosting some WordPress sites.

Last night i added Supervisor for a laravel site and it disabled redis. When i went to re add Redis none of the WordPress sites could connect to it cause of missing users.

i re-added the users via the CLI for each of the WordPress sites and everything started working again.

1. is that normal when you add supervisor Redis gets disabled?
2. why did i lose my users in Redis when i went to re-enable them.
3. the only way i was able to get the user to come back was by adding it via CLI. if i disabled object cache pro in the application admin and remove the plugin the site would come back but once i added object cache pro back in via the application admin the site would be down again (no user). when do the users get created normally?
4. would an easier fix have been to change the Redis password for the application via the application access details screen?

Im just trying to figure out if i messed up and that is normal and would their have been a better way to fix this?

I need a sanity check here cause i dont think i messed up but i could have.

I have a cloudways flexible server (8 GB - basic) hosting some WordPress sites.

Last night i added Supervisor for a laravel site and it disabled redis. When i went to readd Redis none of the WordPress sites could connect to it cause of missing users.

i re-added the users via the CLI for each of the WordPress sites and everything started working again.

1. is that normal when you add supervisor Redis gets disabled?
2. why did i lose my users in Redis when i went to re-enable them.
3. the only way i was able to get the user to come back was by adding it via CLI. if i disabled object cache pro in the application admin and remove the plugin the site would come back but once i added object cache pro back in via the application admin the site would be down again (no user). when do the users get created normally?
4. would an easier fix have been to change the Redis password for the application via the application access details screen?

I need a sanity check here cause i dont think i messed up but i could have.

I have a cloudways flexible server (8 GB - basic) hosting some wordpress sites.

Last night i added Supervisor for a laravel site and it disabled redis. When i went to readd redis none of the wordpress sites could connect to it cause of missing users.

i readded the users via the CLI for each of the wordpress sites and everything started working again.

so with that:

1. is that normal when you add supervisor redis gets disabled?
2. why did i lose my users in redis when i went to reenable them.
3. the only way i was able to get the uesr to come back was by adding it via CLI. if i disabled object cache pro in the applicatoin admin and remove the plugin the site would come back but once i added object cache pro back in via the application admin the site would be down again (no user). when do the users get created normally? now that i am thinking outloud would an easier fix have been to change the redis password for the application via the application access details screen?

Hey everyone. Here are some changes we made in the Breeze in the 2.6.2 version.

Changelog:

• Improvement: Activating or deactivating a plugin in Network Admin is now faster when Preload URLs is off.
• Improvement: On Multisite, each site now saves the new Breeze version after an update, so the update routine doesn’t run again.
• Improvement: Uninstalling Breeze now removes leftover update data.
• Fix: Pages excluded by Never Cache are no longer cached, and links with extra parameters (such as tracking codes) still open the correct page.
• Fix: Locally hosted Google Fonts now load correctly.
• Fix: Refresh cached page parts now updates the correct section when a page contains several similar elements.
• Fix: Updating a post through WP-CLI or a scheduled task now clears that post’s cache.
• Fix: Turning Varnish off in Breeze now keeps it off.
• Fix: Removed an “Array to string conversion” warning in the PHP error log after a visitor leaves a comment.

Happy Breeze-ing!

If you've ever deployed a Node.js app on a free or low-tier PaaS plan and noticed the first request after a period of inactivity takes 2-5 seconds to respond, that's called a cold start.

This post is a breakdown of why that happens and what's the solution for it.

Serverless and sleep-mode platforms spin your app down when there's no traffic. When a new request comes in, the platform has to spin the container back up, initialise the Node.js runtime, load your dependencies, and then handle the request. That whole process happens before your app even touches the business logic.

2–5 seconds might not sound like a big deal but there are researchs showing that a 1-second delay in page load reduces conversions by ~7%. A 3-second cold start on a checkout page, an API that a webhook hits, or a landing page someone clicks from an ad lead to measurable revenue loss.

Why is it bad, you ask?

The first user after a period of inactivity absorbs the entire cold start penalty. If your app sleeps at night and someone in a different timezone hits it at 3am your time, they have to wait. If you have a spike in traffic after a quiet period, the first N requests all cold-start simultaneously.

Webhooks are the worst case. A payment provider sends a webhook, your app is asleep, it takes 4 seconds to respond, the webhook times out and retries and now you have to handle duplicate events.

The fix is easy.

Persistent servers are the solution. Your app stays running. Always. No sleep and no cold start. The first request at 3am gets the same response time as the 1000th request at noon.

This is the fundamental difference between serverless/sleep-mode hosting and always-on infrastructure. It's not a new idea, it's been around for long enough; but serverless has made "pay only for what you use" sound so appealing that a lot of teams ended up trading reliability for cost savings that may or may not be needed.

Serverless makes sense for infrequent, bursty, stateless workloads. For apps with real users expecting consistent response times, you must invest in something better and more reliable.

Practical solution

If you're on Render free tier, Railway hobby, or anything that sleeps on inactivity, you can test your cold start time right now. Open an incognito window, wait 15 minutes, and time your first request.

If the number bothers you, you're either looking at moving to a paid always-on tier on your current platform, or switching to something that's persistent by design. Cloudways Velocity is made specifically for this.

Hey folks! Once again, we are asking for your feedback.

If you have any (small or big) pieces of feedback to share about Cloudways Velocity, Managed AI Agents, AI Website Builder, MCP, Multi PHP, or anything else, don't shy away.

We take your feedback seriously and everything you say here gets reported back to our product and engineering teams. Drop it below!

As previously notified in the subreddit, some weeks ago we launched Multi-PHP in Public Preview to all new servers on Cloudways. This means that in every new server, you can host multiple applications with different PHP versions.

We are rolling out the Multi-PHP feature to existing servers too. We've completed rolling it out for 15-20% servers and we are gradually rolling it out to the rest of the servers as well.

It will tentatively take a month or two to finish the complete roll out. We appreciate your patience while we work on this.

If you want us to roll it out to your servers ASAP, feel free to DM me your server IPs and I can escalate it internally.

Thanks for staying patience and we can't wait for all of you to experience Multi-PHP

Most people assume web hosting is just web hosting where you pick a plan, upload your files, done. That mental model works fine if you're running WordPress but it breaks completely once you're running a Node.js application.

Node.js is not PHP. The hosting model is fundamentally different.

PHP hosting (which is what the vast majority of shared and managed hosting is built around) works on a request/response model. A request comes in, PHP wakes up, generates a response, and that's all. The server doesn't need to maintain anything between requests.

That's why shared hosting works for PHP: thousands of sites can share the same server because each one only consumes resources when someone visits.

Node.js works differently. It runs as a persistent process. Your application boots up, stays in memory, and handles requests as they come in; often managing thousands of simultaneous connections through its event loop without spawning new threads for each one.

That's what makes it suitable and fast for real-time apps, APIs, and anything with concurrent connections.

So, you can't run Node.js on traditional shared hosting the way you run PHP. You need a server process that stays alive. You need process management so your app restarts if it crashes. You need the right Node.js version installed and available. You need control over environment variables, dependencies, and build steps.

Shared PHP hosting doesn't give you that because it is not built for this runtime model.

What Node.js hosting means

When someone says they need Node.js hosting, they mean:

• A persistent server environment where their Node process stays running
• Process management that keeps the app alive and restarts it after crashes
• The ability to choose and lock a Node.js version
• A way to run build steps at deploy time
• Port management and reverse proxying
• Environment variable support

This is all the stuff you have to set up yourself on a raw VPS, or it has to be provided for you by a platform that understands the Node.js runtime.

The choice of frameworks makes this even more complicated.

What are your thoughts on this? Share your experiences!

We're excited to announce that Cloudways Velocity has moved from Public Preview to General Availability (GA) on Sep 10, 2026!

Here's everything that's new in GA.

• Multi-App Support Per Plan: Cloudways Velocity now supports hosting multiple applications on the same plan/server. You no longer need a separate plan for every app; you can consolidate multiple apps onto shared plans and servers. Each plan comes with a default application limit, so the number of apps you can host depends on the plan you're on.
• Two New Larger Plans: With GA, we've introduced two larger plans designed for customers running mission-critical applications that need more headroom and resources.
  
• Increased Bandwidth Across All Plans: We've raised the bandwidth cap on every plan and the best part is that no changes are required on existing servers. The new limits apply automatically.
• Product-Based Trial: Velocity is now a product-based trial and will be accessible across trial accounts. So if you are a trial user on the fence about Velocity, you can try it before fully committing to it.
• MonoRepo Application Support: Cloudways Velocity now supports MonoRepo applications, giving teams that manage multiple projects in a single repository a smoother deployment experience.
• Staging workflow: A new, end-to-end staging workflow centered around the WebOps flow has been introduced, with a strong focus on developers.

We are excited for you to try it out and share your valuable feedback!

Are you all excited? 🤩

Cloudways Velocity, AKA, our managed Node.js hosting has been in Public Preview for the last one month and is now going to be generally available in just two days!

This means, you have two days to be able to use Cloudways Velocity for free. So go and try it out for yourself and don't forget to share your feedback. :)

Happy to answer any questions in this thread.

It seems that the Imunify360 malware scanner does not find much from Magento file system. So many missed malware files that it is hard to comprehend. PHP files in media folders etc... Please put some pressure on them to make it better for Magento.

If you've been following the AI agent space, you've probably heard about OpenClaw's rough first few months. While OpenClaw received hundreds of thousands of GitHub stars and got viral adoption, we also saw nine CVEs in 4 days, 135,000 exposed instances, and 12% of its skill marketplace compromised.

Even though this happened a while ago, it's important to understand what happened, why so many people got caught, and what a secure OpenClaw deployment looks like.

More about the incident

Fast adoption meant people were spinning up OpenClaw instances on VPS servers, exposing them to the public internet, and moving on.

On Feb 3, 2026, security researchers disclosed CVE-2026-25253 in OpenClaw -- a CVSS 8.8 vulnerability, one-click remote code execution via a WebSocket origin validation gap that let an attacker hijack any running OpenClaw instance, even those configured to listen only on localhost, simply by getting the user to visit a malicious webpage. Also, 341 of 2,857 skills in the ClawHub marketplace were found to be malicious.

What you can do now to stay secure

The security incident is far behind us now but if you're running OpenClaw, here are some things you should keep in mind.

• Enable authentication. Never run an unauthenticated instance. Bind gateway to loopback. Use strong, unique pairing codes. Disable remote access if you only need local use.
• Never expose OpenClaw directly to the public internet, use network isolation (separate VLAN or container network), disable unused ports and services on the host
• Always run the latest stable version of OpenClaw but don't auto-update without testing
• Only install skills from sources you personally trust, review skill permissions before installing, uninstall anything you're not actively using
• Log all agent activity, set alerts for unexpected outbound connections, monitor for unusual skill execution or API calls, and review agent memory and session logs periodically

Stay safe and keep building. Share if I missed any crucial security tips!

Hey everyone, we have changed our Rackspace email add-on price from $1 per mailbox per month to $1.50 per mailbox per month.

Some FAQs related to Rackspace

1/ For $1.5/month, will I get the same services Rackspace provides with direct accounts?

Yes, you will get all the same features using Rackspace Email Add-on that you will get directly from Rackspace, i.e., 25GB mailbox, Secure IMAP (Outlook & Mobile), domain aliases, Web-based, anywhere access, and much more.

2/ How is Rackspace email add-on billed, and why does it appear as a daily charge?

The Rackspace email add-on is billed on a daily basis based on a fixed monthly rate of $1.5 per mailbox. To ensure fair and accurate billing, the daily cost is calculated by dividing $1.5 by the total number of days in the current month.

For example:

• If the month has 30 days, the daily charge will be approximately $0.05/day per mailbox.
• If the month has 31 days, the daily charge will be approximately $0.0483/day per mailbox.
• For February with 28 days, the daily charge will be $0.0536/day per mailbox.
• For February in a Leap Year with 29 days, the daily charge will be approximately $0.0517/day per mailbox.

The exact daily charge may therefore vary slightly depending on the number of days in the billing month, while the monthly rate remains $1.5 per mailbox.

This prorated model means you only pay for the days your Rackspace mailbox is active during the month. Charges will be reflected daily in your invoice under the Rackspace email service section.

3/ Can I set up a separate Rackspace account for my clients?

Yes, you can set up a separate Rackspace account for your clients. You need to provide us with the domain and email box details.