How to run Stable Diffusion WebUI (AUTOMATIC1111) on a cloud GPU

Stable Diffusion WebUI, usually referred to as AUTOMATIC1111 or A1111, can run on a cloud GPU in much the same way it runs on a local Linux workstation. You launch a GPU virtual machine, install the WebUI and a Stable Diffusion checkpoint, then forward its browser interface securely to your own computer.

On an RTX 5090, there is one extra detail worth knowing before you start: use the AUTOMATIC1111 dev branch rather than blindly following older installation instructions. The current dev branch uses a Blackwell-compatible PyTorch build with CUDA 12.8, while many older guides still assume GPUs and CUDA versions from before the RTX 50 series.

The setup in this guide uses:

• 1 × NVIDIA RTX 5090 with 32GB VRAM
• an Ubuntu virtual machine
• Python 3.11
• the AUTOMATIC1111 dev branch
• an SDXL checkpoint
• SSH port forwarding to reach the WebUI

You do not need two GPUs for ordinary interactive Stable Diffusion use. In fact, adding another GPU does not simply combine both cards' VRAM inside one AUTOMATIC1111 process.

If you are still deciding what hardware your image workflow needs, start with our Stable Diffusion hardware and VRAM guide.

What is Stable Diffusion WebUI?

Stable Diffusion WebUI is an open-source browser interface for Stable Diffusion created by the AUTOMATIC1111 project.

It wraps the underlying image-generation models in a graphical interface, so you can work with text-to-image, image-to-image, inpainting, upscaling, LoRAs, extensions, prompt controls, samplers, and other tools without building the whole pipeline yourself.

The browser interface can be misleading at first because it looks like a hosted web application. It isn't.

The WebUI runs on the machine doing the computation. Your browser simply connects to it.

That machine can be:

• your desktop PC
• a workstation
• a remote server
• a rented cloud GPU

Using a cloud GPU means the model and WebUI run on the remote GPU while you control them from your normal browser.

Why run AUTOMATIC1111 in the cloud?

Running locally is sensible when you already own a capable GPU and use Stable Diffusion frequently.

Cloud GPUs make more sense when your usage is intermittent, your local GPU does not have enough VRAM, you need a faster card for a particular project, or you do not want to buy hardware before knowing how much you will actually use it.

The tradeoff is straightforward.

Local hardware gives you permanent access after the upfront purchase. Cloud compute replaces that purchase with an hourly operating cost and requires some server setup.

For someone generating images a few hours a week, that can be a much easier calculation than buying a high-end GPU that sits idle most of the time.

For longer-running production workloads, you should calculate the cost rather than assuming cloud rental will always be cheaper.

How much GPU memory does AUTOMATIC1111 need?

AUTOMATIC1111 itself is not the main VRAM problem. The models and workflows you run inside it are.

A basic Stable Diffusion 1.5 workflow can work on GPUs with modest amounts of VRAM. SDXL, high-resolution generation, multiple ControlNets, large batches, upscaling, and more elaborate pipelines push memory requirements higher.

For comfortable modern Stable Diffusion work, 12GB to 16GB gives you much more room than an entry-level GPU.

The RTX 5090 has 32GB of VRAM, which gives SDXL and more demanding image workflows considerable headroom.

If you want a deeper explanation of what 32GB actually buys you across AI workloads, see our RTX 5090 VRAM guide.

More VRAM does not mean every generation becomes proportionally faster. Once the model fits comfortably, GPU compute performance, memory bandwidth, resolution, sampler, number of steps, batch size, and workflow design all affect generation time.

Start with one RTX 5090

For this setup, use a single RTX 5090 cloud GPU.

This is worth spelling out because renting two GPUs sounds like an obvious way to make AUTOMATIC1111 twice as fast.

That is not how a standard A1111 process works.

AUTOMATIC1111 lets you select which CUDA GPU a process uses, but it does not normally pool the VRAM of several GPUs into one larger memory space for image generation. If you want to use several GPUs for throughput, the usual approach is to run separate processes or workers assigned to different cards.

For an interactive WebUI used by one person, start with one good GPU.

Scale only when you have a workload that benefits from parallel generation.

Step 1: launch an RTX 5090 virtual machine

Sign in to Compute with Hivenet and create a new instance.

Choose:

1. Virtual machine
2. your preferred region
3. 1 × RTX 5090
4. Ubuntu
5. SSH connectivity

Use a virtual machine for this guide rather than a container.

AUTOMATIC1111 needs several system packages, and the installation is simpler when you have normal Ubuntu package management and sudo access. Containers are useful for managed application environments, but a VM gives us the conventional Linux system the WebUI expects.

If this is your first Compute instance, the Compute quickstart covers instance creation and SSH access in more detail.

Once the VM is running, connect using the SSH command shown under Connectivity options.

Step 2: make sure the RTX 5090 is available

Before installing anything, check that the operating system can see the GPU:

nvidia-smi

You should see the NVIDIA GPU and its driver information.

Do this before debugging Python, PyTorch, or Stable Diffusion. If nvidia-smi cannot see the GPU, installing another Python package will not solve the underlying problem.

Step 3: install the Linux dependencies

Update the package list:

sudo apt update

Install Git and the system libraries used by AUTOMATIC1111:

sudo apt install -y \
 wget \
 git \
 software-properties-common \
 libgl1 \
 libglib2.0-0

AUTOMATIC1111's Linux launcher supports Python 3.11, while a current Ubuntu installation may give you a newer Python version by default.

Add Python 3.11:

sudo add-apt-repository -y ppa:deadsnakes/ppa
sudo apt update
sudo apt install -y python3.11 python3.11-venv

Check it:

python3.11 --version

Step 4: install the AUTOMATIC1111 dev branch

Clone the project:

git clone \
 --branch dev \
 https://github.com/AUTOMATIC1111/stable-diffusion-webui.git

Then enter the directory:

cd stable-diffusion-webui

Why the dev branch?

The current AUTOMATIC1111 dev branch installs PyTorch 2.7.0 with CUDA 12.8 by default. PyTorch 2.7 introduced Blackwell GPU support, including pre-built CUDA 12.8 wheels.

The RTX 5090 is a Blackwell GPU.

This matters because older AUTOMATIC1111 installations and many tutorials use PyTorch versions built before Blackwell support existed. Those installations can detect an RTX 5090 while still failing when they attempt to execute CUDA kernels.

The AUTOMATIC1111 dev branch and PyTorch's Blackwell support notes are the useful sources to check if these versions change after this article is published.

Step 5: tell AUTOMATIC1111 to use Python 3.11

Open its Linux configuration file:

nano webui-user.sh

Find:

#python_cmd="python3"

Change it to:

python_cmd="python3.11"

For now, leave the command-line arguments simple:

export COMMANDLINE_ARGS="--port 7860"

Save the file.

There is a reason we are not piling optimization flags into the first launch.

Get the plain configuration working first.

Flags such as --xformers, memory optimizations, extensions, custom attention backends, and other tweaks add more variables when something fails. Once you can generate an image, you have a known-good baseline to optimize.

Step 6: launch Stable Diffusion WebUI

Run:

bash webui.sh

On the first launch, AUTOMATIC1111 creates its Python virtual environment and installs its dependencies.

That takes longer than subsequent starts.

Once the application has finished loading, the terminal should show that the WebUI is listening on port 7860.

Do not close this SSH session yet.

Step 7: add a Stable Diffusion model

The WebUI is an interface. It still needs a model checkpoint to generate images.

For a clean baseline, you can use Stability AI's Stable Diffusion XL Base 1.0.

AUTOMATIC1111 looks for Stable Diffusion checkpoints in:

stable-diffusion-webui/models/Stable-diffusion/

From the WebUI directory, you can download the official SDXL checkpoint:

wget \
 -O models/Stable-diffusion/sd_xl_base_1.0.safetensors \
 "https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors"

The checkpoint is several gigabytes, so give it time to finish.

Before using any model in your own work, read its license and model card. The fact that a checkpoint is downloadable does not mean every model has identical terms for commercial use, redistribution, or derivatives.

Restart AUTOMATIC1111 after adding the checkpoint if it does not appear automatically.

Step 8: connect to the WebUI securely

You could expose port 7860 publicly.

For a personal WebUI, there is usually no reason to.

SSH port forwarding keeps the interface reachable from your computer without turning it into a public web service.

On your local computer, open a second terminal.

Take the SSH command shown by Hivenet for the instance and add:

-L 7860:localhost:7860

For example:

ssh \
 -L 7860:localhost:7860 \
 ubuntu@<instance-id>.ssh.hivecompute.ai

Your exact SSH command may differ, so use the one shown in the Compute console rather than copying the placeholder literally.

Then open:

http://localhost:7860

in your browser.

Your browser is now talking to port 7860 on your own machine, which SSH securely forwards to the Stable Diffusion WebUI running on the cloud GPU.

Hivenet has a separate port-forwarding guide if you need to troubleshoot the connection.

Step 9: generate your first SDXL image

In the AUTOMATIC1111 interface:

1. Select the SDXL checkpoint.
2. Open txt2img.
3. Enter a simple prompt.
4. Start at 1024 × 1024 for SDXL.
5. Use a batch size of 1.
6. Generate the image.

Keep the first test boring.

You are checking that:

• the checkpoint loads
• CUDA works
• the GPU is actually used
• the WebUI generates successfully
• the browser connection remains stable

You can watch GPU memory and utilization from another SSH terminal:

watch -n 1 nvidia-smi

Once the basic generation works, start changing samplers, steps, batch size, resolution, LoRAs, upscalers, extensions, and other settings.

Changing ten things before the first successful image makes troubleshooting needlessly difficult.

Where AUTOMATIC1111 stores your files

A few directories become important quickly.

Stable Diffusion checkpoints:

models/Stable-diffusion/

LoRAs:

models/Lora/

Embeddings:

embeddings/

Generated images are normally stored under:

outputs/

A serious image-generation workspace can grow faster than expected. Model checkpoints commonly take several gigabytes each, and LoRAs, ControlNet models, generated images, upscaled versions, and training files accumulate on top.

Do not treat disk planning as an afterthought simply because the GPU gets most of the attention.

Can you install extensions?

Yes.

AUTOMATIC1111 has a large extension system, which is part of the reason people still use it.

Extensions can add tools for ControlNet, image browsing, regional prompting, face processing, model management, and many other workflows.

They also add third-party code to the environment.

Install extensions deliberately rather than collecting them.

An extension can bring its own Python dependencies, pin versions that conflict with your existing environment, consume additional VRAM, or stop working after a WebUI update.

If your setup suddenly breaks after installing an extension, remove the extension from the equation before reinstalling the entire GPU environment.

Should you enable xFormers on the RTX 5090?

The AUTOMATIC1111 dev branch currently supports an xFormers version intended to work with its PyTorch 2.7 setup.

That does not mean --xformers should be your first move.

First get the default configuration running.

Then, if you want to test xFormers, add it to webui-user.sh:

export COMMANDLINE_ARGS="--port 7860 --xformers"

Restart the WebUI and compare the workload that matters to you.

Measure generation time and VRAM use with the same checkpoint, prompt, resolution, sampler, steps, and batch size.

A performance flag is useful when it improves your actual workflow. The name of an optimization is not evidence that your setup became faster.

Does AUTOMATIC1111 use multiple GPUs?

A standard AUTOMATIC1111 process normally uses one selected GPU.

If a server contains several GPUs, you can choose which one it uses through CUDA_VISIBLE_DEVICES or the WebUI's device options.

What you should not expect is for two 32GB RTX 5090s to automatically behave like one 64GB GPU inside a single A1111 session.

If you need parallel image generation, you can run several WebUI processes and assign each process to a different GPU.

That can improve total throughput for a queue of independent jobs.

For an individual interactive session, renting several GPUs before you have a parallel workload is usually wasted capacity.

AUTOMATIC1111 or ComfyUI?

They solve a similar problem in different ways.

AUTOMATIC1111 is easier to approach when you want a conventional interface with controls for prompting, img2img, inpainting, LoRAs, extensions, and common Stable Diffusion operations.

ComfyUI exposes the image pipeline as a node graph.

That makes ComfyUI harder to approach at first and much easier to reason about once workflows become complex, reusable, or heavily customized.

If you want to generate images interactively and adjust familiar controls, A1111 remains useful.

If you are constructing pipelines where the exact flow between model loaders, conditioning, samplers, ControlNet, upscalers, and outputs matters, I would choose ComfyUI.

We'll cover that setup separately in our ComfyUI cloud GPU guide.

For newer models such as FLUX, ComfyUI is also often the more natural place to work. Our planned FLUX.1 [dev] cloud GPU guide will use that route rather than forcing every image model through the same interface.

How much does running AUTOMATIC1111 in the cloud cost?

The calculation is mostly GPU time.

At Hivenet's current published RTX 5090 rate of €0.75 per GPU-hour, a single-GPU instance costs:

Compute uses per-second billing while the instance is running.

That matters for this kind of workload because image generation is often bursty. You may work for an hour, stop for lunch, then continue later.

When you stop the instance, compute billing stops and the environment is preserved temporarily. Hivenet currently keeps stopped instances for up to five days before automatic termination, so do not use a stopped VM as permanent storage.

When you terminate an instance, its data is deleted.

Back up checkpoints, custom models, outputs, workflows, and anything else you need before terminating it.

Current Compute pricing is available on the Hivenet pricing page.

A better way to think about cloud image generation

The question is often framed as whether running Stable Diffusion locally or in the cloud is cheaper.

That skips the useful question: what kind of capacity do you actually need, and how often?

If you generate every day on the same machine for years, buying hardware can make economic sense.

If you occasionally need a large GPU, move between models with different requirements, work in bursts, or want to test a workflow before committing to hardware, renting capacity is easier to justify.

The important part is to stop the instance when you stop using it.

Cloud economics become bad quickly when an idle GPU is left running overnight.

For broader image-generation and rendering workloads, see rendering and compute-heavy workloads with Hivenet.

Stable Diffusion WebUI FAQ

What is Stable Diffusion WebUI?

Stable Diffusion WebUI is a browser-based interface for running Stable Diffusion image models. The best-known implementation is the open-source AUTOMATIC1111 project.

Is AUTOMATIC1111 the same as Stable Diffusion?

No. Stable Diffusion refers to the image-generation models. AUTOMATIC1111 is software that provides an interface for loading and using those models.

Is AUTOMATIC1111 free?

The AUTOMATIC1111 software is open source and does not require a subscription. You still need hardware to run it, and individual model licenses can have their own conditions.

Can I run AUTOMATIC1111 on a cloud GPU?

Yes. Install it on a GPU server or virtual machine and connect to its browser interface remotely. SSH port forwarding is a simple way to access the interface without exposing it publicly.

Does AUTOMATIC1111 work on the RTX 5090?

Yes, but use a PyTorch version with NVIDIA Blackwell support. The AUTOMATIC1111 dev branch currently uses PyTorch 2.7 with CUDA 12.8, which added Blackwell support.

How much VRAM does AUTOMATIC1111 need?

It depends mainly on the model and workflow. Older Stable Diffusion models can operate with relatively little VRAM, while SDXL, high-resolution generation, ControlNet, large batches, and other additions need more. A 32GB RTX 5090 gives modern image workflows substantial room.

Does AUTOMATIC1111 support SDXL?

Yes. Add a compatible SDXL checkpoint to the models/Stable-diffusion directory and select it from the WebUI.

Does AUTOMATIC1111 use two GPUs at once?

A normal A1111 process generally uses one GPU rather than pooling memory across several cards. Multiple GPUs are more useful for running separate generation workers in parallel.

What port does AUTOMATIC1111 use?

The WebUI normally uses port 7860 unless you configure another port.

Should I expose port 7860 to the internet?

For personal use, SSH tunneling is safer and usually simpler. If you intentionally expose the WebUI publicly, configure authentication and network access carefully rather than leaving an unrestricted generation interface on the internet.

Should I use AUTOMATIC1111 or ComfyUI?

AUTOMATIC1111 is easier for conventional interactive image generation. ComfyUI is better suited to explicit node-based workflows and complex pipelines. Neither interface is universally better; the useful choice depends on how you work.

‍