CloudCruise product updates after May 8, 2026: what actually shipped.

Section one

What shipped, per repo, with the actual last-push timestamp.

The CloudCruise GitHub organisation has five public repos. Four are actively maintained engineering surfaces (the JS, Python, and CLI SDKs plus the BADGER DSL spec). One, test-websites, has not been touched since September 2025 and is out of scope for a product-updates question. Below is the inventory, sorted by most-recent push, with the answer to the literal question in the first row.

Read the table top to bottom and the shape of CloudCruise's engineering allocation since their March 2026 seed becomes obvious. Active work happens on the SDKs. BADGER is treated as a published spec, not a moving target. The DSL has been stable for over three months, which is a feature if you are integrating against it and a tell about where the closed-source runtime is getting most of the attention.

Section two

Re-verify the answer yourself in three commands.

This page's answer is dated and will go stale. Below is the exact recipe used to produce it, so you can re-run it the day you read this and check whether anything changed. Requires curl and jq, both standard on macOS and any Linux distribution. No API key.

The first command lists every public CloudCruise repo with its last-push timestamp. Anything newer than the date you arrived on this page is fresh. The second pulls the five most-recent commits on the JS SDK, which is the repo most likely to receive feature work. The third scrapes any 2026-shaped date out of the blog HTML, which is rough but reliable enough to catch new posts. Three commands, under five seconds, no auth.

Section three

The one commit after May 8, in detail.

The post-May-8 update is small enough to describe in a paragraph. The cloudcruise-js SDK previously allowed the API key to be sent to any endpoint the caller pointed it at. After commit 35400dd, the SDK rejects API key requests to anything other than the production CloudCruise API. The change is sensible: a leaked SDK key pointed at a staging or local-mock endpoint is the classic shape of a token-exfiltration bug, and constraining the SDK at the source means a downstream developer cannot accidentally create that vector even with a misconfigured wrapper.

For a buyer doing diligence, two things are worth noting. One, the team is still actively maintaining the JavaScript SDK with engineering attention in the same month they shipped a CLI minor. Two, the change shape (defensive, fingerprintable, short) is the kind of patch that happens after a security review or an incident report from a customer. Neither is publicly disclosed, and the commit message does not say. The honest reading is: the JS SDK got tightened on May 11, and the team has not yet shipped a public statement about why.

The cloudcruise-cli v1.2.0 release on May 8 is more interesting as a directional signal. The new --version-number flag and the “feat(workflows): support fetching prior workflow versions” commit (4da02e5) together imply the platform is moving toward versioned workflow artefacts that can be retrieved out-of-band, which is the prerequisite for any rollback or A/B testing flow on a graph. The CLI ships before the platform feature is announced, which is a common pattern: the SDK lands first so partner integrations can be tested, the blog post follows when the marketing site is ready. Worth watching for a follow-up post in the next two to four weeks.

Section four

Where to watch, and what you will not find.

CloudCruise has chosen not to publish a changelog. There is no /changelog page (returns 404), no tagged releases on any GitHub repo, and no status page. The team communicates through the blog for announcements and through commit history for the day-to-day, which is a reasonable choice for a small developer-platform company but means a buyer has to do the work of compiling updates themselves.

Section five

How to read “not much changed” as a buyer.

A five-day quiet window in May is not a vendor-health signal. It is a five-day quiet window. CloudCruise shipped a $5M seed in March 2026, two substantive blog posts in late April, three healthy SDK releases in late April and on May 8, and a security patch on May 11. The cadence is fine. The flat patch on May 8 through 13 is the kind of thing that happens to every small team in any given week.

What it means for a buyer doing diligence right now is mostly that the recent feature commitments (versioned workflows, SDK hardening) are credible directional signals and you can plan a pilot against them. If you are deciding whether to wait for a specific feature, the honest answer is to ask CloudCruise directly, not to read tea leaves out of a commit log.

The harder question for most buyers is not about cadence at all. It is whether a browser-only RPA platform fits the workflow you are actually trying to automate. CloudCruise drives anything that lives inside Chromium. The moment the workflow opens a desktop SAP GUI screen, an Epic Hyperspace window, an Oracle Forms session, or a Jack Henry green-screen, the DOM stops being a meaningful representation and a different surface is needed. Mediar reads the Windows UI Automation accessibility tree instead, which exposes role, name, automation id, and bounds for every visible control across every running Windows process. Same idea (workflow file plus selector cascade plus AI authoring), different input surface. Teams running both let the browser tool handle the browser steps and the desktop tool handle the desktop steps inside one end-to-end flow.