How to run ComfyUI in the cloud on an RTX 5090

Running ComfyUI in the cloud can mean two different things.

Comfy Cloud is the official hosted ComfyUI service. You open it in a browser and Comfy provides the GPU, models, software, and environment.

Self-hosted ComfyUI on a cloud GPU gives you a remote Linux machine where you install ComfyUI yourself. You choose the GPU, models, custom nodes, storage layout, software versions, and when the instance runs.

This guide covers the second approach.

We'll set up ComfyUI on:

• 1 × NVIDIA RTX 5090 with 32GB VRAM
• a Linux virtual machine
• a current PyTorch CUDA build
• the official ComfyUI repository
• ComfyUI-Manager
• SSH port forwarding for browser access

Once it is running, the same installation can support image, video, audio, and other graph-based generative workflows.

That last point is why ComfyUI deserves its own guide rather than being treated as another Stable Diffusion interface.

What is ComfyUI?

ComfyUI is an open-source, node-based interface and inference engine for generative AI.

Instead of hiding the generation pipeline behind a conventional control panel, it represents the pipeline as a graph.

A basic image workflow might look conceptually like this:

Load model
   ↓
Encode prompt
   ↓
Create latent image
   ↓
Sample
   ↓
Decode
   ↓
Save image

Each box is a node.

Connections between nodes pass models, text conditioning, images, latents, masks, numbers, or other data from one operation to the next.

The result is a visual description of exactly what the generation pipeline is doing.

That makes ComfyUI particularly useful for workflows that become awkward in a conventional interface:

• multiple LoRAs
• ControlNet
• image-to-image pipelines
• inpainting
• staged upscaling
• FLUX workflows
• video generation
• several model passes
• reusable preprocessing and post-processing
• batch generation
• API-driven pipelines

The official ComfyUI documentation describes a workflow as a graph of connected nodes capable of generating images, video, audio, and other outputs.

The important word is workflow.

ComfyUI is useful because the graph itself can become a reusable artifact.

Comfy Cloud and self-hosted ComfyUI are different products

Comfy now offers its own hosted service called Comfy Cloud.

The official service currently runs on NVIDIA RTX 6000 Pro GPUs and provides pre-installed models and custom nodes. You do not manage the underlying machine.

That is the easiest route if you simply want to use ComfyUI.

Self-hosting on Compute with Hivenet adds infrastructure work but gives you control over:

• the exact GPU
• model files
• custom nodes
• Python packages
• software versions
• disk layout
• network access
• workflows
• update timing
• when the GPU starts and stops

The distinction is similar to the one we made in our Ollama Cloud versus self-hosted GPU guide.

A managed cloud service gives you the application.

A rented GPU gives you the machine.

Choose the machine when controlling the machine solves a problem you actually have.

Why run ComfyUI on a cloud GPU?

ComfyUI itself does not require an RTX 5090.

Your workflow determines the useful hardware.

A modest Stable Diffusion workflow can run on much smaller GPUs. Newer image and video models can consume far more VRAM.

Cloud GPUs become useful when:

• your local GPU does not have enough VRAM
• you only need expensive hardware intermittently
• you want to test models before buying hardware
• a workflow takes too long locally
• you need different hardware for different projects
• you want a reproducible remote environment
• you are building a workflow that will later run as a service or batch job

The RTX 5090 gives you 32GB of VRAM.

That is considerably more room than many consumer GPUs and makes it suitable for demanding image-generation workflows and some newer generative-video pipelines.

Our RTX 5090 VRAM guide explains why the amount of free memory around a model matters as much as whether the base model technically loads.

ComfyUI or AUTOMATIC1111?

Both can run Stable Diffusion-style image-generation models.

They approach the problem differently.

AUTOMATIC1111 gives you a conventional interface. Parameters are grouped into panels, tabs, extensions, and controls.

ComfyUI exposes the generation pipeline itself.

If your workflow is:

Load a checkpoint, type a prompt, adjust a few settings, generate an image.

AUTOMATIC1111 can be easier.

If your workflow becomes:

Load this model, apply these two LoRAs, condition one region with ControlNet, run one sampler, pass the result through another model, upscale it, and save several intermediate outputs.

ComfyUI is easier to reason about because you can see the pipeline.

We cover the other route in our Stable Diffusion WebUI and AUTOMATIC1111 cloud GPU guide.

You do not need to pick one interface for the rest of your life.

Use the one that fits the workflow.

What GPU does ComfyUI need?

ComfyUI has no meaningful fixed GPU requirement.

A workflow can load one small image model or several enormous image and video models.

Useful variables include:

• checkpoint size
• model precision
• resolution
• batch size
• ControlNet models
• LoRAs
• VAEs
• upscalers
• video length
• frame resolution
• number of model stages
• custom-node behavior

The GPU requirement belongs to the workflow rather than the interface.

That distinction becomes increasingly important as ComfyUI expands beyond Stable Diffusion.

A FLUX image workflow and a Wan video workflow can both run inside ComfyUI while having completely different memory profiles.

We'll treat those separately in our FLUX.1 [dev] cloud GPU guide and upcoming Wan 2.2 ComfyUI cloud GPU guide.

For a general-purpose cloud ComfyUI machine, 32GB gives you useful room without requiring a multi-GPU instance from the start.

Step 1: launch one RTX 5090 virtual machine

Create an instance in Compute with Hivenet.

For this setup, choose:

1. Virtual machine
2. 1 × RTX 5090
3. Ubuntu or another current Linux environment
4. enough disk space for your models and outputs
5. SSH access

A VM makes sense because ComfyUI environments tend to evolve.

You may install:

• system libraries
• Python packages
• custom nodes
• command-line tools
• additional model download utilities

Having normal operating-system control makes that easier.

If this is your first instance, use the Compute quickstart.

Connect over SSH and confirm that the GPU is visible:

nvidia-smi

Do this before installing ComfyUI.

You should see the RTX 5090 and its available GPU memory.

Step 2: create an isolated Python environment

ComfyUI changes frequently, and custom nodes can bring their own dependencies.

Do not install everything into the system Python environment.

Check your Python version:

python3 --version

ComfyUI currently recommends Python 3.13 and identifies Python 3.12 as a good fallback when custom-node dependencies cause compatibility problems.

For a server where you expect to experiment with third-party nodes, Python 3.12 is a conservative choice.

Create a virtual environment:

python3 -m venv ~/comfy-env
source ~/comfy-env/bin/activate

Upgrade pip:

pip install --upgrade pip

From now on, make sure this environment is active when you install or update ComfyUI packages.

Step 3: install the current NVIDIA PyTorch build

ComfyUI's current manual installation instructions recommend the stable PyTorch CUDA 13.0 packages for NVIDIA GPUs.

Install them with:

pip install \
 torch \
 torchvision \
 torchaudio \
 --extra-index-url https://download.pytorch.org/whl/cu130

Then check the GPU from Python:

python - <<'PY'
import torch

print("PyTorch:", torch.__version__)
print("CUDA available:", torch.cuda.is_available())

if torch.cuda.is_available():
   print("GPU:", torch.cuda.get_device_name(0))
   print(
       "VRAM:",
       round(
           torch.cuda.get_device_properties(0).total_memory
           / 1024**3,
           1
       ),
       "GB"
   )
PY

You want CUDA to return:

True

and the device name to show the RTX 5090.

This check separates GPU problems from ComfyUI problems.

Step 4: install ComfyUI

Clone the official repository:

git clone https://github.com/Comfy-Org/ComfyUI.git

Enter it:

cd ComfyUI

Install the application dependencies:

pip install -r requirements.txt

ComfyUI can now be started with:

python main.py

The default web interface runs on port:

8188

Keep it bound to the remote machine's local interface for now.

There is no need to expose the application publicly just to reach it from your laptop.

Step 5: enable ComfyUI-Manager

Custom nodes are an important part of the ComfyUI world, and the current ComfyUI-Manager is built into ComfyUI core.

For manual installations, its dependencies still need to be installed and the feature enabled.

From the ComfyUI directory:

pip install -r manager_requirements.txt

Then launch:

python main.py --enable-manager

The Manager can help install, update, and diagnose custom nodes.

That convenience deserves some caution.

A custom node is code running inside your ComfyUI environment.

Treat custom nodes as software dependencies, not as harmless visual presets.

Install nodes because a workflow requires them. Avoid building an environment around dozens of abandoned packages you no longer know how to reproduce.

Step 6: access ComfyUI securely through SSH

Do not start by binding ComfyUI to every network interface with:

--listen 0.0.0.0

For an individual remote workspace, SSH tunneling is simpler and keeps the ComfyUI server on localhost.

Leave ComfyUI running on the VM:

python main.py --enable-manager

On your own computer, open a second terminal and add this to the normal SSH connection command for the Hivenet instance:

-L 8188:localhost:8188

Conceptually:

ssh \
 -L 8188:localhost:8188 \
 <your-hivenet-ssh-target>

Then open:

http://localhost:8188

in your browser.

Your browser connects to port 8188 on your computer. SSH forwards that traffic securely to port 8188 on the remote GPU machine.

Hivenet documents the same approach in the port-forwarding guide.

There is another reason to prefer this over a public --listen configuration: ComfyUI-Manager deliberately restricts some higher-risk operations when ComfyUI is exposed beyond localhost, and some partner-node features also require a secure local environment.

The easiest remote ComfyUI setup is often the one that still behaves locally from the application's point of view.

Step 7: understand a ComfyUI workflow before downloading twenty of them

When ComfyUI opens, the canvas contains connected nodes.

A simple text-to-image graph generally performs these jobs:

Checkpoint
   ↓
Text conditioning ──┐
                   ↓
Latent image → Sampler
                   ↓
                  VAE
                   ↓
               Save image

The exact node names depend on the model and workflow.

The important concept is that the workflow describes the inference process.

A node may:

• load a model
• encode text
• load an image
• create a mask
• apply conditioning
• sample latent noise
• decode a latent
• resize an image
• save a file

Links describe how data moves between them.

This explicit structure is why ComfyUI workflows can become useful infrastructure artifacts instead of disposable UI settings.

ComfyUI workflows can be saved as JSON

A ComfyUI workflow can be exported as a JSON file.

For example:

portrait-workflow.json

That JSON describes the node graph and its settings.

You can later reopen it through:

Workflows → Open

This makes workflows:

• portable
• versionable
• inspectable
• shareable
• reproducible
• suitable for automation

The word reproducible needs one qualification.

The JSON graph does not magically bundle every checkpoint, LoRA, custom node, and Python dependency it refers to.

A workflow can therefore describe the same pipeline while still failing on another machine because a required model or node is missing.

The workflow is the recipe.

The environment still needs the ingredients.

ComfyUI also stores workflow metadata inside generated images

One of ComfyUI's cleverer features is that generated images can contain the workflow that produced them in their metadata.

That means you can often take a PNG created by ComfyUI and drag it back onto the canvas.

ComfyUI reconstructs the workflow.

The official documentation explicitly supports loading workflows from:

• workflow JSON
• images containing ComfyUI workflow metadata

This makes generated files useful debugging artifacts.

If an image came out well, you can inspect how it was produced instead of trying to remember fourteen settings from last Thursday.

The same principle makes team workflows much easier to share.

Workflows matter more than screenshots of settings

A screenshot tells someone what your interface looked like.

A workflow tells ComfyUI what to do.

For serious work, save the workflow.

If you are iterating on a production pipeline, I would keep versions such as:

product-shot-v01.json
product-shot-v02-controlnet.json
product-shot-v03-upscale.json

or keep the JSON in version control.

That gives you a history of changes you can actually inspect.

This is one reason comfyui workflows is such an important part of the subject. The workflow graph is the durable unit of work in ComfyUI.

Step 8: add the model your workflow needs

Self-hosted ComfyUI does not mean every model is installed automatically.

Models are normally stored under:

ComfyUI/models/

with subdirectories such as:

checkpoints/
loras/
vae/
controlnet/
clip/
diffusion_models/
upscale_models/

The exact files depend on the workflow.

Do not download a random checkpoint simply because a tutorial uses it.

Before adding a model, check:

• its model card
• license
• precision
• expected directory
• VRAM requirement
• whether the workflow needs separate text encoders or VAEs
• whether it is compatible with the custom nodes you are using

Modern ComfyUI pipelines often involve several model files rather than one .safetensors checkpoint.

That becomes particularly visible with FLUX and video-generation workflows.

You can share model files between ComfyUI and AUTOMATIC1111

Large model files consume disk quickly.

If the same VM contains both ComfyUI and AUTOMATIC1111, you do not necessarily need duplicate checkpoint collections.

ComfyUI supports:

extra_model_paths.yaml

for adding model directories outside the normal ComfyUI/models tree.

Its official example even includes an AUTOMATIC1111 layout.

That means a single underlying model library can potentially serve several interfaces.

The useful idea is broader than A1111:

Keep large model assets separate from disposable application environments when your workflow permits it.

Applications are easy to reinstall.

A carefully curated collection of model files can occupy hundreds of gigabytes.

Custom nodes are where reproducibility gets harder

Suppose somebody sends you:

perfect-workflow.json

You open it and see red boxes labelled as missing nodes.

The JSON is valid.

Your environment is incomplete.

Custom nodes can introduce:

• new operations
• model loaders
• video tooling
• post-processing
• APIs
• convenience functions
• dependency conflicts

ComfyUI-Manager can identify and install many missing nodes.

That is useful for exploration.

For a workflow you intend to rely on, document the environment too.

At minimum, keep:

• the workflow JSON
• model names and versions
• custom-node list
• important Python dependencies
• ComfyUI version or commit
• any environment variables

If you cannot reconstruct the environment, you do not yet have a reproducible pipeline.

Save a snapshot before changing a working environment

Once a ComfyUI setup becomes useful, resist the urge to update everything simultaneously.

ComfyUI itself changes quickly.

So do custom nodes.

A workflow that works today can break because:

• a node changes its inputs
• a package upgrades
• a model loader is renamed
• PyTorch changes
• a custom node stops being maintained

ComfyUI's current CLI and Manager tooling include environment snapshot and management functions for precisely this reason.

For experimental environments, updates are fine.

For a workflow someone depends on tomorrow morning, treat updates as changes that need testing.

The newest environment is not automatically the most reliable one.

How much disk does a ComfyUI cloud setup need?

More than the application itself suggests.

ComfyUI is small.

Models are not.

A workspace can accumulate:

• checkpoints
• diffusion models
• text encoders
• VAEs
• ControlNet weights
• LoRAs
• upscalers
• custom-node caches
• input images
• generated images
• generated video
• temporary files

Video is particularly effective at turning “plenty of disk space” into “where did the disk go?”

Choose instance storage around the model library and output volume rather than the size of ComfyUI's Git repository.

And remember that an instance filesystem is not a substitute for a backup.

Move anything you need to keep before terminating an ephemeral compute environment.

ComfyUI becomes much more useful when workflows become code-like

The visual editor is only one interface to the workflow.

ComfyUI can also operate as a server, and workflows can be submitted programmatically.

The current Comfy CLI can run exported workflow JSON against a local ComfyUI server.

For example:

comfy run \
 --workflow my_workflow.json \
 --wait

This changes the role of ComfyUI.

The graph can be built and debugged visually, then reused from:

• scripts
• batch jobs
• internal tools
• queues
• automation
• applications

You do not have to rebuild the entire inference pipeline in Python simply because you want to call it from software.

A visual workflow can become a machine-readable pipeline.

GUI workflow and API workflow are related, but not identical concepts

This is worth understanding before automating ComfyUI.

The workflow you edit visually contains UI information such as node positions and canvas state.

The server cares about the execution graph.

Comfy's current CLI can accept exported UI-format JSON and convert it to the API format needed for execution.

That means you can continue designing workflows visually without manually translating every graph into a different file before scripting it.

For teams working with generative media, this can be a useful division of labor:

1. build and test the pipeline visually
2. save the workflow
3. put it under version control
4. run the same graph from automation

The workflow becomes the boundary between experimentation and production.

ComfyUI is not just an image interface anymore

Calling ComfyUI an “AI image generator” is increasingly incomplete.

Its workflow system can connect tools for:

• images
• video
• audio
• 3D
• model processing
• external AI APIs
• multimodal pipelines

The underlying graph model is flexible enough that an output from one system can become input to another.

For example, a workflow might:

Generate image
     ↓
Upscale
     ↓
Use image as video input
     ↓
Generate video
     ↓
Post-process frames
     ↓
Save

This is where ComfyUI becomes substantially different from a prompt box wrapped around one model.

The model is one component.

The workflow is the system.

Why ComfyUI is particularly useful for FLUX

FLUX workflows often involve separate model components and explicit loading choices that map naturally onto a graph.

ComfyUI also lets you see precisely where text encoding, model loading, sampling, decoding, and post-processing happen.

That makes it a good fit for experimenting with different precision and memory configurations on a 32GB GPU.

We'll use ComfyUI as the main interface in our FLUX.1 [dev] cloud GPU guide.

That article will focus on FLUX itself rather than repeating the installation work here.

And video is where the graph becomes even more useful

Video-generation pipelines often contain more stages and larger intermediate data than image workflows.

You may have:

• source image
• text prompt
• video model
• VAE
• frame generation
• interpolation
• resolution settings
• output encoding

Representing those operations explicitly becomes useful when troubleshooting performance and VRAM.

Our upcoming Wan 2.2 ComfyUI cloud GPU guide will build on this setup and concentrate on what video generation changes.

How much does a self-hosted ComfyUI GPU cost?

Hivenet currently lists the RTX 5090 from €0.75 per GPU-hour, with per-second on-demand billing.

That gives:

Those numbers describe GPU access.

‍

‍

They do not describe cost per image.

A workflow producing one 4K video sequence and one producing a 512 × 512 image are not economically comparable because both ran for “one generation.”

For generative-media economics, measure:

• wall-clock generation time
• images or frames produced
• resolution
• batch size
• GPU utilization
• failure rate
• number of usable outputs

Then calculate around the creative workload.

The most expensive workflow is often the one that runs for hours producing output you discard.

Current Compute rates are on the Hivenet pricing page.

Comfy Cloud or an RTX 5090 instance?

Use Comfy Cloud when:

• you want zero setup
• the available models and nodes cover your workflow
• you do not want to maintain the environment
• you want the official hosted Comfy experience
• managing GPU infrastructure adds no value

Use self-hosted ComfyUI on an RTX 5090 when:

• you want specific model files
• you need custom nodes outside a managed catalog
• you care about the exact GPU
• you want control over updates
• you want your own model directory
• you are benchmarking workflows
• you want to expose the workflow through your own service
• usage patterns make on-demand GPU rental sensible

Comfy's own documentation draws much the same line: Cloud gives you a pre-installed hosted environment, while self-hosting gives you control over the models and nodes you install.

There is no virtue in operating the server yourself.

Do it when the control is useful.

Don't expose an experimental ComfyUI server casually

A ComfyUI environment can contain:

• arbitrary custom nodes
• model download tools
• filesystem access
• API integrations
• credentials
• generated assets
• Manager operations

Treat it like an application environment, not a harmless static webpage.

For individual remote use, keeping the service on localhost and using an SSH tunnel is a good default.

If you turn it into a shared service, add an intentional security layer around it.

Opening port 8188 to the internet is connectivity.

It is not access control.

What should you back up?

Before terminating the GPU instance, decide what is actually valuable.

Usually that means:

Definitely keep

• workflow JSON
• custom model files you created
• LoRAs you trained
• important generated assets
• custom nodes you modified
• configuration files

Usually reproducible

• ComfyUI itself
• standard PyPI packages
• public model files
• public custom nodes

A good cloud workflow treats the compute instance as replaceable.

If destroying the VM destroys your only copy of an important workflow, the problem is storage design rather than ComfyUI.

A useful ComfyUI project structure

For serious work, I would keep project material conceptually separate from the application:

project/
├── workflows/
│   ├── image-v01.json
│   ├── image-v02.json
│   └── video-v01.json
├── inputs/
├── outputs/
├── notes/
│   └── environment.md
└── models.md

Then document:

ComfyUI version
Required custom nodes
Required model files
Relevant model licenses
GPU configuration
Important environment settings

You do not need a complicated MLOps platform to make a workflow reproducible.

A small amount of discipline is enough.

ComfyUI cloud FAQ

What is ComfyUI?

ComfyUI is an open-source node-based interface and inference engine for generative AI. Workflows are represented as graphs of connected operations rather than a conventional set of generation controls.

What is Comfy Cloud?

Comfy Cloud is the official hosted version of ComfyUI. Comfy manages the infrastructure, models, custom nodes, and updates. It currently uses NVIDIA RTX 6000 Pro GPUs.

Can I run ComfyUI on my own cloud GPU?

Yes. ComfyUI can be installed on a normal Linux GPU VM in the same way it can be installed on a local Linux workstation.

Does ComfyUI work on the RTX 5090?

Yes. Current ComfyUI installation guidance supports NVIDIA GPUs through current PyTorch CUDA builds, and an RTX 5090 provides 32GB of VRAM for model workflows.

How much VRAM does ComfyUI need?

There is no fixed amount. The models, resolution, batch size, LoRAs, ControlNet, video pipeline, upscalers, and other workflow components determine memory use.

What port does ComfyUI use?

ComfyUI uses port 8188 by default.

How do I access remote ComfyUI safely?

For a personal GPU VM, keep ComfyUI bound to localhost and forward port 8188 over SSH. Then open http://localhost:8188 on your own computer.

What is a ComfyUI workflow?

A workflow is a graph of connected nodes describing how ComfyUI should generate an output. Nodes load models, process prompts and images, perform sampling, decode results, and carry out other operations.

Are ComfyUI workflows JSON files?

They can be. ComfyUI workflows can be exported and reopened as JSON, making them portable and suitable for version control and automation.

Can a ComfyUI image contain its workflow?

Yes. Images generated by ComfyUI can contain workflow metadata that lets ComfyUI reconstruct the graph when the image is loaded back into the interface.

Can ComfyUI workflows be automated?

Yes. ComfyUI has server APIs and its current CLI can submit workflow JSON for execution, allowing graphs designed visually to become repeatable jobs.

Does ComfyUI include ComfyUI-Manager?

The current Manager is built into ComfyUI core, but manual installations need its dependencies installed and the Manager enabled when ComfyUI starts.

What are ComfyUI custom nodes?

Custom nodes are third-party or additional code that adds operations to the workflow graph. They can extend ComfyUI substantially but should be treated as software dependencies because they execute code inside the environment.

Can ComfyUI and AUTOMATIC1111 share models?

Yes. ComfyUI supports additional model search paths through extra_model_paths.yaml, including layouts used by AUTOMATIC1111.

Is ComfyUI better than AUTOMATIC1111?

Neither is universally better. AUTOMATIC1111 is often easier for conventional interactive Stable Diffusion generation. ComfyUI gives you explicit, reusable workflow graphs and is better suited to complex or automated pipelines.

Is ComfyUI only for Stable Diffusion?

No. Current ComfyUI supports workflows across images, video, audio, 3D, external AI APIs, and other generative-media tasks.

‍