RocketRide runs .pipe files on a C++ runtime, and the docs disagree on how many nodes exist

A pipeline is a .pipe file, which is what makes it reviewable

The design decision that shapes everything else is that a pipeline is data, not code you import. The README says pipelines are defined as portable JSON, built visually in VS Code and executed by a multithreaded C++ runtime, and the format carries the .pipe extension. The examples/ directory shows what that means in practice: rag-pipeline.pipe, rag-rerank-pipeline.pipe, document-processor.pipe, slack-agent.pipe, agent-llamaindex.pipe, tool-pipe-nested.pipe, tool-pipe-diamond.pipe, llm-benchmark.pipe, n8n-roundtrip.pipe and graph_falkordb.pipe sit side by side, alongside a pipe-diff-example.md.

That last file matters more than the others for an engineer reviewing a change. A pipeline that lives in git as JSON can be diffed, reviewed and reverted like a config file, and a diff of a node graph is something a colleague can read without knowing the Python API. The trade is that a node graph can grow into a large JSON document whose structure is not checked by a compiler, and the repository does not include a schema validator in the scripts that package.json declares, whose entries are prepare, check:action-pins, lint:scripts and test:action-pins.

Local pulls the engine into the editor, so production means a second target

Installation is an editor extension, not a shell command, and the Quick Start has three steps: install the extension for your IDE by searching for RocketRide in the extension marketplace, click the extension, then deploy a server. The prompts ask how you want to run it, and the two options the guide spells out are Local, marked Recommended, which pulls the server directly into your IDE with no additional setup, and On-Premises, which runs the server on your own hardware. The extension is on the VS Code Marketplace and on the Open VSX Registry, so editors other than VS Code have a route.

The consequence is that the recommended path is a development path. A workload that has to survive a closed laptop needs a target other than Local. The project names three beyond Local: Docker, on-premises, and RocketRide Cloud, where the stated pitch is that the vendor operates the engine and your .pipe runs unchanged.

package.json pins vcpkg, JDK 17 and pnpm 10 for a zero setup claim

The features table advertises managed dependencies, saying Python environments, C++ toolchains, Java and Tika, and all node dependencies are handled for you, with a clone, build and run and no manual setup. The build configuration is where the real prerequisites show. package.json pins a vcpkg version of 2026.07.29, a JDK version of 17 and a Maven version of 3.9.6, and its engines block requires Node 20.0.0 or newer and pnpm 10.0.0 or newer, with [email protected] declared as the package manager. The prepare script runs lefthook install --force on install.

For a contributor that means three toolchains are expected to be present and versioned, C++, Java and Node, even though the engine itself is C++ and the node layer is Python. The two are reconciled rather than removed, and the reconciliation lives in the build. One more field is worth noting for anyone looking for the engine on npm: the manifest is marked private, so nothing is published from this repository under the name rocketride-server. The TypeScript SDK is a separate package named rocketride, and the Python SDK is a separate project on PyPI.

Nodes extend in Python, under ruff rules that a vendored parser sits outside of

Extension happens in Python. The features table states that all nodes are Python-extensible and that you can build and publish your own, the repository has a nodes/ directory, and the contributing path the project advertises is claiming an issue with one comment and adding a node in Python. The lint configuration at the top of the repository shows what a node author inherits. Ruff runs with a line length of 120, a target version of py310, single quotes as the quote style, and the E, F, Q and D rule groups selected, which is a docstring enforcement set rather than a formatting choice.

The exclusion list is the more interesting part, because it names a subsystem. Vendored third-party code under an Apache-2.0 license, including ANTLR generated parsers, is kept out of lint through force-exclude, and the two directories named are _agtype and _cypher under packages/ai/src/ai/common/graph/age. A Cypher parser for the AGE graph extension sitting inside the Python tree tells you the graph query layer is vendored rather than reached through a package. The project records where that code came from, in a README next to it, which is the kind of detail that matters when you are deciding whether to patch inside it.

Two page-level node counts, 50 plus on one and 100 plus on the other

The project's own two descriptions do not agree. The repository description says a C++ core with 50 or more Python-extensible nodes, 13 or more model providers and 8 or more vector databases. The README says 100 or more pipeline nodes spanning 15 or more LLM providers and 9 vector databases, and the features table repeats 100 or more nodes with 15 or more providers. The README is the more recent and more detailed of the two, and it is the one that also lists the node categories, OCR, NER, PII anonymization, chunking strategies and embedding models, so the gap is probably a stale summary rather than a shrinking product.

It still costs a reader something. Anyone sizing an evaluation, counting integrations or writing a procurement note meets both numbers and has no way to resolve them without reading the repository. Neither figure is broken down by category either, so you cannot tell from the documentation which of the two is counting nodes and which is counting configurations. The same page also links an MCP server at docs.rocketride.org/connect/mcp/http, which is how a pipeline is exposed as a callable tool to an AI assistant rather than run by one.

Three version streams, and the newest tags on all three are prereleases

Versioning here is per artifact, and the release list shows it. The three most recent tags are RocketRide Server v3.5.0 prerelease, RocketRide Python Client v1.5.0 prerelease and RocketRide TypeScript Client v1.5.0 prerelease, all dated 2026-11-02. The two clients are on 1.5.0 while the server is on 3.5.0, and package.json on the default branch, which is develop and not main, reads version 3.5.0 with private set to true.

Two things follow for anyone pinning this. First, a reproducible environment needs three version numbers, not one. Second, the newest artifacts available are prereleases, so an install script that takes the latest tag gets a prerelease by default. The supporting files for this are conventional and present: CHANGELOG.md, RELEASE.md, SECURITY.md, renovate.json for dependency updates and pnpm-lock.yaml beside pnpm-workspace.yaml for a multi-package tree.

Supply chain checks are scripted, and the agent configuration is in the repository

The trust controls are unusually visible for a project at this stage. Two of the four scripts in package.json exist to check the build's own inputs, check:action-pins running node scripts/verify-action-pins.mjs and test:action-pins running the matching test file:

node scripts/verify-action-pins.mjs

Pinning action versions is a supply chain measure. Alongside it sit .gitleaks.toml and .gitleaksignore for secret scanning, .env.template and user.template.json for the configuration a user is expected to fill in, a devcontainer directory, and a NOTICE file next to the MIT LICENSE.

There is a second kind of automation to weigh. The repository carries .coderabbit.yaml, .cursorrules, AGENTS.md and a .claude/ directory, and the features table says RocketRide auto-detects a coding agent, naming Claude and Cursor, so pipelines can be built and modified through natural language. That is a feature and a review surface at the same time. A .pipe file produced by an agent is JSON describing model calls, prompts and tools, and the same scripts directory is where you would look for the checks that would tell you what changed.

CrewAI, LangChain and n8n are the named neighbours, and the examples go both ways

The features table claims built-in CrewAI and LangChain support for multi-agent workflows, with agents chained, memory shared across pipeline runs and multi-step reasoning managed. Those are Python libraries that run inside your process, which is a different execution model from a .pipe file handed to a separate multithreaded C++ runtime. The distinction decides where your code lives and what happens when it fails: an exception in an agent library surfaces in your application's stack, a node failure surfaces in the engine.

The n8n examples show the boundary being negotiated rather than declared. The repository contains n8n-call-rocketride.workflow.json, which calls RocketRide from n8n, and n8n-roundtrip.pipe, which points the other way. n8n is a workflow tool with its own nodes and its own execution model, and the project ships round-trip files for both directions instead of a migration guide. Read that as a statement about how the two compose. Read the absence of a comparison against LangGraph, Airflow or a plain asyncio service as the honest limit of what these files tell you.

Editorial conclusion

Adopt RocketRide if you want AI pipelines as reviewable files in git rather than as Python objects, and if you can accept a monorepo that pins a C++ toolchain through vcpkg, a JDK 17 and a pnpm workspace. Do not adopt it if you need one stable version number, since the server, the Python client and the TypeScript client are versioned separately and the newest tags are prereleases. Check the node count first, because the repository description and the README give different figures.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes