A Pipeline Is a File. Running It Is the Work.

#ai #opensource #mlops #llm

Why we built RocketRide Cloud around the same portable .pipe files developers use locally.

By Krish Garg and Mithilesh Gaurihar

The artifact we want a team to own is small.

It is a .pipe file: a JSON description of the nodes in an AI workflow, the data lanes between them, and the configuration each node needs. You can open it in an editor, review it in a pull request, and keep it with the application it belongs to.

The job we do not think every team should have to own is everything required to keep that file working for real users.

That is the distinction behind RocketRide Cloud.

We did not set out to make another place to draw agent graphs. Plenty of products can help you make a demo. We wanted the thing you build locally to stay the thing you run in production, without asking you to become the team that operates GPU inference, identity, secrets, routing, deploys, and the failures in between.

The pipeline is yours. Running it is the work.

Start with the file

Here is a real RocketRide pipeline. A dropper takes in a media file, a parser prepares it, an audio-transcribe node turns its audio into text, and an output node returns that text.

{
  "components": [
    { "id": "dropper_1", "provider": "dropper", "name": "Dropper",
      "config": { "mode": "Source", "type": "dropper", "hideForm": true } },
    { "id": "parse_1", "provider": "parse", "name": "Parser",
      "input": [{ "lane": "tags", "from": "dropper_1" }] },
    { "id": "audio_transcribe_1", "provider": "audio_transcribe", "name": "Transcribe",
      "config": { "profile": "default",
        "default": { "model": "base", "min_seconds": 240, "max_seconds": 300, "silence_threshold": 0.25, "vad_level": 1 } },
      "input": [{ "lane": "video", "from": "parse_1" }] },
    { "id": "response_text_1", "provider": "response_text", "name": "Return Text",
      "config": { "laneName": "text" },
      "input": [{ "lane": "text", "from": "audio_transcribe_1" }] }
  ],
  "project_id": "00000000-0000-4000-8000-0000000000d0",
  "version": 1
}

That is the application logic. Not the whole production system, obviously, but the part that should stay legible to the people who own it.

The value of a declarative pipeline is not that JSON is fashionable. It is that the runtime can understand what it is being asked to run, and so can you. The source is explicit: the dropper. The steps are explicit. The lanes between the nodes are explicit too, named right there in the file. The dropper hands off to the parser on a tags lane, the parser feeds the transcribe node on a video lane, and the transcribe node returns its output on a text lane. A model provider, a vector store, or a tool is a component with a contract, not a hidden dependency buried in application glue.

That makes a pipeline easier to inspect and easier to change. Swap the transcription model and the surrounding workflow does not need to be rewritten. Add a step and the review is a small diff, not a new service with another deploy path. The visual builder is just another view of the same file.

The file is portable on purpose. It can run locally in the VS Code extension, on infrastructure you operate yourself, or on RocketRide Cloud.

On your machine: the file above, edited in the RocketRide extension. The connection at the bottom points at RocketRide Cloud, and one click deploys your local changes to production.

Local is dev. Cloud is production. Deploy is one click.

This is the part we care about most, so we will say it plainly. In the VS Code extension the same pipeline points at two runtimes: one on your own machine, and RocketRide Cloud. Local is where the work happens. You add a node, connect it, run it, inspect the trace, and try again, against the very same runtime that will run in production. Local development should be boring, and here it is.

Then moving what you built from local to production is not a packaging step. You make the changes locally, and one click deploys them to Cloud. No container to build, no config to fill in, no key to paste, no separate CI to wire up. The pipeline you were editing a second ago is the one now serving your users. Develop, edit, iterate, and when it is ready, one click ships it.

In the cloud: the very same file, now running in production. Nothing was packaged or re-uploaded; the local edits were promoted with a click.

Production is a different job, and that is what the click quietly hands off. A production pipeline needs an authenticated entry point. It needs a place for project state, secrets, and billing. It needs to survive a rolling deploy, a failed process, a slow model load, or a reconnecting client. It needs a route to a model server when the work requires OCR, transcription, embeddings, NER, or vision. It needs someone to watch the runtime itself, not just the prompt.

Those concerns are why Cloud exists.

When you deploy, you are not handing your workflow to a new format or a black box. You are running the same .pipe file on a managed production path. The Cloud runtime supplies the service layer around it: authenticated access, managed endpoints, secrets and project controls, run-level observability, and the infrastructure that keeps the runtime available.

The important part is what does not happen. You do not rebuild the workflow as a separate cloud-only artifact. You do not fork the logic just because it moved from a laptop to a service your users call.

What you are actually handing over

Managed is an overused word, so it is worth being specific about the work that moves to us. Four things, plainly.

A fraction of the cost, on a patent-pending model server. Open-weight models are cheap now, but only to whoever can serve them well. Our model server does that serving: continuous batching to keep the GPU busy, warm caches so shared context is not recomputed, quantized serving to fit more model into less memory, and step-level routing that sends each step to the cheapest model that clears its quality bar. A step that only needs a small model gets one. To be honest about the claim: the saving is in model selection and efficient serving, not in the runtime being cheaper compute than a script you wrote yourself.

Shared pipelines your team actually shares. A pipeline is a first-class object, not a script living on one laptop. One person defines it, and the rest of the team runs it, forks it, and reads the same traces and the same cost data. When a model changes or a step needs work, someone edits one node and everyone is on the same version, instead of six people maintaining six slightly different copies.

The operational layer, handled. Running AI in production means owning authentication and secrets, provider failover, tool isolation, monitoring, and the security posture around all of it. RocketRide Cloud runs that layer so the churn lands on our on-call rotation, not your product. A monthly invoice cannot tell you why one customer request failed. A trace of the run can, and that is the level we operate at.

Performance and scale that survive real traffic. Once a pipeline is resident, repeat requests are served warm instead of paying a cold start every time. I/O-bound work like model calls, retrieval, and database hops overlaps cleanly rather than running one call after another. Shared state lets the service route work across healthy instances rather than pinning a pipeline to one process, and health checks and controlled shutdowns mean a deploy does not become a dropped request by default.

That is not the glamorous part of AI. It is the part that becomes your problem the first time a demo turns into a dependency.

For an engineering leader, the question is not whether the team can stand up those pieces. Most good teams can. The question is whether that is the best use of their time while they are still learning whether the product itself is useful.

Why the runtime is written this way

Under the file is a C++ runtime that orchestrates Python nodes. That design is deliberate, but it is not a magic performance claim.

The runtime is there to supervise work, keep the pipeline contract stable, and isolate failure boundaries. It does not make every piece of Python suddenly parallel, and it does not make a model reason better. In production the useful question is often simpler: when a node fails badly, what else does it take down with it?

RocketRide runs pipeline work under supervision so one broken run does not become an outage for every other request. That choice has a cost. Process isolation adds lifecycle work that a throwaway in-process script does not have. We made the trade because production systems are judged by how they fail, not only by how they look on the happy path.

Cloud is where that trade becomes practical. It is one thing to have a runtime that can supervise a run. It is another to operate the surrounding services, update the runtime, manage GPU-backed model serving, and keep the path healthy over time. That is not a burden a product team should inherit by accident just because it wanted to ship an AI feature.

Why not self-host?

This is the right question, and sometimes the answer is that you should.

Self-host RocketRide Server when your environment requires it. If your data has to stay inside a particular VPC, if you run an air-gapped deployment, or if you already have a platform team that wants to own the runtime, the MIT-licensed server is there for exactly that. The .pipe file you author is still yours, and it still runs.

Cloud is for the other case: a team that wants to ship a production AI capability without first becoming responsible for the operations around it. Same portable workflow, but with RocketRide operating the service path behind it.

That is a different thing from lock-in. We do not think a managed service earns its place by making departure hard. It earns its place when it is genuinely easier to run well than to run yourself. The open-source runtime makes that claim more credible, not less. You can inspect the runtime, use it locally, self-host it later, or keep using Cloud because it saves your team from running another piece of production infrastructure.

The decision is smaller than it sounds

You do not need to make a permanent infrastructure bet before you write the first pipeline.

Author the workflow as a file. Run it locally while the work is changing quickly. Use Cloud when you need an operated production path. Self-host when your environment requires you to own that path.

The important thing is that the application logic does not get trapped in the decision. That is why we built RocketRide this way. The pipeline should belong to the team building the product. The operational burden should be a choice.