Bring Your Own Workload, From the Terminal
The Rotastellar CLI is on npm. Package a program, push it, run it on the fleet, fetch the results. Four commands, no browser.
Over the weekend we published the Rotastellar CLI to npm. It is a small thing, a thin wrapper over the control-plane API with zero dependencies, and it is the first piece of the platform where you bring your own program rather than picking from ours.
npm install -g @rotastellar/cli
rotastellar login --key <your-api-key>
We are still in private beta, so you need an account and a key. If you have one, this post is the tour. If you do not, it is a preview of how the workflow is meant to feel.
Package first
The thing we kept coming back to while designing this is that a workload is a package before it is a job. You build a program. It has a content hash. You register it once. Then you run it, as many times as you want, against whatever the fleet can offer. The job is cheap and disposable. The package is the thing you own.
So the CLI leads with the package.
# dry run: compute the content id and show the manifest, upload nothing
rotastellar workload build ./detector.wasm --kind eo.triage
# register it under your org
rotastellar workload push ./detector.wasm --name ship-detector --kind eo.triage
push content-addresses the file and uploads it directly to object storage through a short-lived presigned URL. The bytes never pass through a browser or through our API servers. The control plane only ever sees the hash, the manifest, and the name you gave it.
The --kind flag matters more than it looks. Every workload kind carries a set of capabilities the program is allowed to use, and the planner uses the kind to decide what a feasible run even means. If you are not sure what to put there:
rotastellar workload types
prints the valid kinds and what each one is allowed to do. We are deliberately not hardcoding that list anywhere in the CLI. It comes from the control plane, so it is the same list the console and the SDKs see.
Then run it
rotastellar workload run pkg_7f3a91c2@1
Or, if you are in a hurry, push and run in one go:
rotastellar workload run ./detector.wasm --name ship-detector
Either way, the control plane takes the package reference, asks the planner for a feasible plan on the fleet, and dispatches it. You get a workload id back immediately.
rotastellar workload results wl_2b8e4d
rotastellar workload results wl_2b8e4d -o ./out
results shows status, outcome, and the result artifacts. With -o it downloads them. The result listing also tells you where each step actually ran and why the planner put it there, which turned out to be the single most asked-for thing in early testing. People want to know that their job ran on board and not on the ground, and they want the reason in one line.
The whole round trip. Program bytes go straight to storage. The control plane handles references, plans, and events. Results come back to you or go to a bucket you own.
Where the results go
By default we custody result artifacts for you, content-addressed, and results -o pulls them down. If you would rather we never hold your output at all, you can configure a sink, a bucket you own, and the fleet delivers there directly. The CLI tells you which happened. If delivery to your sink degraded for any reason and we fell back to custody, it says that too, in plain words, rather than letting you find out later.
What is deliberately not here
There is no deploy a model command. The CLI does not know what a model is. It knows what a package is, what kind it is, and what it is allowed to do, and that is on purpose. We would rather give you a sharp tool for the thing the platform actually does today than a friendly one that implies things it cannot.
There is also no build toolchain. You bring the .wasm, or whichever packaging form your workload kind accepts, built however you like. The CLI’s job starts when you have bytes.
If you are in the beta, go try it. If something is confusing, [email protected] goes to the people who wrote it.