- Immutable versions: Cloud-saved workflows are snapshots (like container images).
- Stable endpoints: A deployment ID/URL doesn’t change, even if you update the workflow version (like a K8s service endpoint stays constant).
- Explicit updates: New workflow versions must be manually applied to deployments (just like updating an image tag in Kubernetes).
- Saving a new cloud workflow version does not automatically change the deployment (like pushing a new image does not automatically update pods).
- If you want to use the new version, you update the deployment spec to point to it—keeping the same deployment ID and endpoint URL.
Concept Mapping
| RunComfy | Kubernetes | Explanation |
|---|---|---|
| Cloud-saved workflow version | Container image (with tag) | Each workflow version is like a built image. It’s immutable and versioned. |
| Deployment | Kubernetes Deployment | A deployment references a specific version/image to run, ensuring consistency. |
| Deployment ID / Endpoint URL | Deployment UID / Service endpoint | These remain stable, even if the version/image inside is updated. |
| Updating workflow version in a deployment | kubectl set image / updating deployment spec | You update the reference to a new version without changing the deployment itself. |
| Saving a new workflow version | Building & pushing a new container image | Creates a new artifact, but doesn’t affect running deployments until updated. |
Visual Comparison between RunComfy Deployment vs. K8s Deployment
