Ryn

2026

Ryn Runtime — making a rented GPU boot the same way every time

I built one Docker image that boots ComfyUI on a rented GPU or my own PC. It pulls its models from my own bucket, checks every file, and stops loudly instead of guessing.

Role
I designed the runtime, set its rules, and verified the full model pull on my own PC
Tools
Docker · CUDA · ComfyUI · Python · Bash · PowerShell · rclone · Cloudflare R2 · RunPod

A rented GPU bills me while it figures out how to start

Ryn Studio sends work to a ComfyUI runtime. For anything heavy, that runtime is a GPU I rent by the hour on RunPod.

Renting is cheap until the machine is confused. A pod that is still installing nodes, downloading models from the wrong place, or crashing at import is still on the meter. And it costs the most when I am asleep and nobody is watching.

So the runtime had one job. Start the same way every time, on any NVIDIA host with a recent driver, and tell me plainly when it cannot.

It is one Docker image. CUDA 13, a pinned ComfyUI release, my two node packs pinned to exact commits, and a small Python tool that fetches and checks the models. The image itself is public on Docker Hub. The models are not in it. The code was largely typed by AI agents working under my direction.

I removed the fallback that was quietly costing me time

Early versions could get models from two places: my own Cloudflare R2 bucket, or Hugging Face if R2 failed.

That sounded safe. It was not. One morning the R2 download was failing on a configuration problem, and the runtime quietly fell back to Hugging Face. It spent 37 minutes pulling from Hugging Face while the real fault stayed hidden. On a rented GPU I would have paid for every one of those minutes and learned nothing.

I chose R2 only. I gave up the safety net, because the safety net was what hid the problem. Now there are three outcomes and no fourth. The models are already valid, so it starts. R2 is not configured, so it stops and names the missing setting. The download fails, so it stops and points at the error.

The next version was a rewrite, not another patch. The folder had become patch over patch, with the same facts in two guides that disagreed. I asked for one source of truth and a Dockerfile written from scratch.

That rewrite made model sets into data. A set is a manifest file in the bucket listing each file, its size and its hash. The image points at one manifest with one setting. A new set means an upload and a changed setting, not a rebuild and a new tag.

Every fix that cost time is now a written reason

Most of the work was not features. It was finding out what a clean Linux machine does that my Windows PC never did.

The image once had no C compiler, and nothing noticed until a generation tried to compile something halfway through. ComfyUI exited at start because it looks for custom nodes relative to a folder I had moved. A PowerShell script died on an em dash because the file had no byte-order mark. A comment on the same line as a value in an env file became part of the value.

Each of those is now a line in the build with the reason next to it. That way the next rewrite cannot quietly undo it.

Two more were about time. Warm boots used to re-hash the whole model set, so now matching sizes skip the slow read. Then I noticed a boot log verifying the same set twice. The download step checked every file, then the startup script checked them all again. Neither step was wrong on its own; nothing owned "only once". The fix was a flag so the check runs once, in the place that can explain a failure.

The proof that the chain works came from my own PC, with no rental at all. The full set, 8 files and 50.36 GB, came down from my bucket and every hash matched.

The image is public and the one-click template comes next

Version 0.5.1 is on Docker Hub at https://hub.docker.com/r/pineapple0wl/ryn-runtime. It is the runtime I test Ryn Studio against, and one real H3 Motion video take has run inside it on my own card, in 277.8 seconds; my image runs so far went through my PC's own ComfyUI instead.

What is not done yet matters as much. There is no public RunPod template, so a stranger still follows a written guide to start one. The container lacks one scheduler my motion recipe uses, so that tool needs a swap on a pod. And the host has to be filtered to CUDA 13 drivers; an older host fails at import with a driver error.

The next version adds that template. The goal is a pod a stranger can start in two minutes without reading anything I wrote.

Outcome

Version 0.5.1 is public at https://hub.docker.com/r/pineapple0wl/ryn-runtime and is the runtime Ryn Studio is tested against.