CloudGPU

Posted on Nov 9

Workspace is not a cloud desktop: four things it does not restore

#machinelearning #gpu #ai #devops

I work on CloudGPU, so read this as a note from the people who build it.

CloudGPU recently added Workspace: you can save project files independently of a GPU, pin them as an immutable version, and restore that version into a later Job or onto a GPU you are already renting. The most common misreading we see is "so it is a cloud desktop now". It is not, and designing around that difference saves real time.

Here are the four things Workspace does not bring back, and what to do about each.

1. Your operating system, drivers and installed packages

A Workspace version is a manifest: relative project paths mapped to files you uploaded and completed. When a Job starts with workspace_version_id, those files are restored into a fresh project directory before your command runs. That is all.

The machine underneath is whatever template the new Job or instance uses. pip install results, a compiled extension, a CUDA build you fixed by hand last week: none of that is in the version.

What to do: keep environment setup as code inside the project. A setup.sh or a pinned requirements.txt / environment.yml that your Job command runs first is the version-controlled replacement for "the machine I had".

# Job command: rebuild the environment, then run
bash setup.sh && python render.py --config configs/shot_014.yaml

2. Changes you made after saving

A version is immutable. If you edit configs/shot_014.yaml on a running GPU, the saved version still holds the old file. Nothing syncs back automatically.

What to do: treat "save a new version" as an explicit step, the same way you treat git commit. Name it after what changed (shot014-fix-lighting), not after the date.

3. Job outputs

The platform does not collect outputs for you. A Job runs one command, and the local storage of that Job's GPU is erased when it ends. If the command did not export its results, they are gone, even if the Job "succeeded".

What to do: make export part of the command, and check it as an acceptance step:

python render.py --out out/ \
  && ls out/*.png | wc -l \
  && <your upload step for out/>

Then verify on your side that the expected number of files arrived and that they open. A zero exit code is not proof that usable files reached you.

4. Unlimited time and unlimited space

Saved files are subject to account eligibility, a quota and a retention policy. Completed files carry an expires_at; downloading a file does not renew it, and a version that contains an expired file becomes unusable. Storage charges are separate from the max_spend_usd cap on a GPU Job, and a budget-limited agent key cannot switch on paid storage.

What to do: read your own limits from the authenticated GET /v1/storage before you plan a long project, and keep your own copy of anything you cannot afford to lose.

So what is it good for?

Three patterns where it genuinely helps:

Repeatable runs. Pass the same workspace_version_id to two Jobs and you know both started from byte-identical project files. If the outputs differ, the cause is elsewhere (seed, environment, upstream model), which narrows the search.
Picking up on a GPU you already rent. A saved version can be applied to a running instance. It lands in a new private directory, does not overwrite your existing files, and does not install anything, run anything or restart the GPU. You decide what happens next.
Handing a project to an agent. An agent with its own scoped key can start a Job from a version without you uploading files again in every session.

A quick mental model

Layer	Survives the GPU?	Who is responsible
OS, drivers, packages	No	Your setup script
Project files you saved as a version	Yes, within quota and retention	Workspace
Edits after the save	No, until you save a new version	You
Job outputs	No, unless exported	Your Job command

A short overview

If you have never seen CloudGPU, this short video shows what it is in general terms (it is not a Workspace tutorial):

Agent and persistence API docs: https://cloudgpu.app/docs/agents?utm_source=devto&utm_medium=article&utm_campaign=202611_seg04_codingagent&utm_content=pack1109gf_devto_workspace_boundary
Check whether persistence is enabled: GET https://cloudgpu.app/v1/public/compute-capabilities

Eligibility and full terms: https://cloudgpu.app/terms?utm_source=devto&utm_medium=article&utm_campaign=202611_seg04_codingagent&utm_content=pack1109gf_devto_workspace_boundary

What does your team keep outside the GPU today: a setup script, a container image, or something else? I am curious which part breaks most often.

DEV Community