The Stable Diffusion WebUI to run in 2026 is Forge Neo, not AUTOMATIC1111 or the original Forge. AUTOMATIC1111's master branch has not changed since July 2024, and lllyasviel's Forge had its last commit in June 2025. Forge Neo, Haoming02's continuation of Forge, still gets commits most days, the latest on 2026-09-28, and runs models the other two never learned, such as FLUX.2 [klein], Qwen-Image, Z-Image and Wan 2.2 14B. It ships its own Dockerfile, so on a QuantaCloud GPU the setup is short: the Bare Metal template, build the image, publish it on 127.0.0.1 only, and open it through an SSH tunnel.
Which WebUI is still maintained#
The honest answer is only one of the three, going by their commit history on 2026-09-28. All three are AGPL-3.0.
| Project | Latest change | Where it stands |
|---|---|---|
| AUTOMATIC1111 stable-diffusion-webui | Master unchanged since 2024-07-27. Its last release, v1.10.1, was published in February 2025. The dev branch last took an installation fix on 2026-03-02 | No feature work for over two years |
| lllyasviel stable-diffusion-webui-forge | Last commit on main on 2025-06-26 | Stopped, and Neo describes itself as its continuation |
| Forge Neo (Haoming02/sd-webui-forge-classic, branch neo) | Commits on 2026-09-24, 25, 26 and 28 | Maintained: PyTorch 2.13 with CUDA 13.0, FLUX.1, FLUX.2 [klein], Qwen-Image, Z-Image, Chroma and Wan 2.2 14B |
Neo keeps the AUTOMATIC1111 interface you know, with its txt2img and img2img tabs, LoRAs and extensions, but it drops some old features: SD2 and SD3 models, hypernetworks and textual inversion training are gone, per its README. If you rely on one of those, check before you move.
Pick a GPU#
Every QuantaCloud GPU has 48 GB or more, which covers the image models Forge Neo runs, such as SDXL, which Stability AI says works on 8 GB cards, Z-Image-Turbo, which its makers say fits 16 GB, and FLUX.1 at full 16-bit, whose [dev] version is under a non-commercial licence. I would start on the RTX A6000, at $0.48/GPU-hr.
The GPU generation matters for the Docker build, though. The Dockerfile installs a CUDA 12.6 build of PyTorch by default, which needs driver 560 or newer and has no kernels for Blackwell cards, so on the RTX PRO 6000 Blackwell you build with CUDA 13.0 instead, which needs driver 580 or newer. The build step below shows both.
Launch an Ubuntu GPU VM on an RTX A6000The Bare Metal template is QuantaCloud's plain Ubuntu 22.04 VM with the NVIDIA driver and Docker. The GPU VPS page lists what is on it and the checks to run on a new VM.
Check that Docker can see the GPU#
Connect over SSH as ubuntu (SSH docs), then check the driver and run a GPU container:
nvidia-smi
sudo docker run --rm --gpus all ubuntu nvidia-smi
The first command's header shows the driver version: 560 or newer for the default build, 580 or newer for the CUDA 13.0 build. The second should print the same GPU table from inside a container. If Docker answers could not select device driver "" with capabilities: [[gpu]], install and configure the NVIDIA Container Toolkit:
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
Running Docker with NVIDIA GPUs explains the toolkit and --gpus in more depth.
Build the Forge Neo image#
Forge Neo's repository has a docker folder with its own Dockerfile. It clones the current neo branch while it builds, creates a Python 3.13 environment and installs PyTorch, so each build picks up the latest commit:
git clone https://github.com/Haoming02/sd-webui-forge-classic sd-webui-forge-neo --branch neo
cd sd-webui-forge-neo/docker
sudo docker build -t forge-neo-local .
# on the RTX PRO 6000 Blackwell, build against the CUDA 13.0 PyTorch instead:
# sudo docker build --build-arg TORCH_INDEX=cu130 -t forge-neo-local .
Run it on 127.0.0.1 with your own folders#
The one thing I always check with a WebUI on a cloud VM is who can reach its port. Forge has no login by default, and a plain -p 7860:7860 would publish it on the VM's public address, past ufw, because Docker writes its own firewall rules. Publishing on 127.0.0.1 keeps it on the VM, and the SSH tunnel in the next section brings it to your browser. Docker releases older than 28.0.0 also let hosts on the same network segment reach ports published to 127.0.0.1, so check the Engine version with sudo docker version first.
The container runs as user 99 in group 100, so give that user the folders you mount for models, outputs, extensions and settings:
mkdir -p ~/forge/models/{Stable-diffusion,text_encoder,VAE,Lora,ControlNet,ESRGAN,embeddings} ~/forge/{output,extensions,config}
sudo chown -R 99:100 ~/forge
sudo docker run -d --name forge --gpus all \
-p 127.0.0.1:7860:7860 \
-v ~/forge/models:/home/forge/sd-webui/models \
-v ~/forge/output:/home/forge/sd-webui/output \
-v ~/forge/extensions:/home/forge/sd-webui/extensions \
-v ~/forge/config:/home/forge/sd-webui/config \
forge-neo-local
sudo docker logs -f forge
On the first start, Forge installs its remaining requirements inside the container, which takes a few minutes. Wait for the log to print its local URL on port 7860.
Anything you add after the image name goes to Forge's launch.py, so forge-neo-local --api turns on the API. Inside the container Forge listens on all interfaces, which is what lets Docker forward the port, and the 127.0.0.1 in -p is what keeps it private.
Open Forge through an SSH tunnel#
From your own computer, forward the port and leave the command running:
ssh -N -L 7860:127.0.0.1:7860 ubuntu@<instance-ip>
Then open http://127.0.0.1:7860 in your browser. The page talks to Forge through the encrypted SSH connection, and nothing else on the internet can reach it. Connecting to a cloud GPU covers SSH config files and VS Code on the same instance. If you ever do expose the port instead, start Forge with --gradio-auth user:password at the very least.
Put models in the right folders#
Forge Neo reads everything from the models folder you mounted, so ~/forge/models on the VM is the place to download to:
| Folder under models | What goes there |
|---|---|
Stable-diffusion | Checkpoints and diffusion models, such as SDXL or Z-Image-Turbo |
text_encoder | Text encoders for models that ship them separately, such as Qwen3 4B for Z-Image |
VAE | VAE files |
Lora | LoRAs |
ControlNet | ControlNet models |
ESRGAN | Upscalers |
embeddings | Textual inversion embeddings |
For a first test, download SDXL 1.0 base, one 6.94 GB checkpoint under the CreativeML Open RAIL++-M licence, which allows commercial use:
sudo curl -fL -o ~/forge/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
sudo chown -R 99:100 ~/forge/models
Click the refresh button next to the checkpoint menu, pick the file, and generate. For a newer model, Z-Image-Turbo is Apache-2.0 and comes as three files: z_image_turbo_bf16.safetensors in Stable-diffusion, qwen_3_4b.safetensors in text_encoder and ae.safetensors in VAE, 20.69 GB together (our calculation). Choose its text encoder and VAE in the selector next to the checkpoint menu. The Download Models page in Neo's wiki lists the files for every model it supports.
Save your images before you stop#
Copy your images off before you press Stop. Stopping a QuantaCloud instance terminates it and deletes its disk, with the image you built, the models and every output, and there are no volumes or snapshots to keep them. Forge writes txt2img results to output/txt2img-images, and that output folder is ~/forge/output on the VM, so from your own computer:
rsync -avP ubuntu@<instance-ip>:forge/output/ ./forge-output/
On the next launch you rebuild the image and download the models again, so keep the commands from this page in a script. Moving files to and from a GPU server covers rsync and scp in more depth.
Forge questions#
Is AUTOMATIC1111 still maintained?
Not in any practical sense. Its master branch has not changed since July 2024, and its dev branch has only taken occasional installation fixes, the last on 2026-03-02. Forge Neo keeps the same interface and still gets regular commits.
Should I use Forge or ComfyUI?
Use ComfyUI if you want QuantaCloud's ready-made template and ComfyUI's built-in workflow templates, and Forge Neo if you prefer the AUTOMATIC1111 layout of tabs and settings. The ComfyUI page has the template on every GPU, running ComfyUI on a cloud GPU walks through it, and ComfyUI in Docker follows the same do-it-yourself Docker route as this page.
Can I use my AUTOMATIC1111 models and LoRAs?
Yes for SD 1.5 and SDXL checkpoints and their LoRAs: put them in Stable-diffusion and Lora. SD2 and SD3 checkpoints and hypernetworks are not supported in Neo.
Why not just open port 7860 to the internet?
Because Forge answers anyone who reaches the port unless you add --gradio-auth, and a Docker port published without 127.0.0.1 bypasses ufw. The tunnel keeps it private with no extra setup.
What does it cost?
You pay the GPU's hourly price from launch to stop, and Forge Neo itself is open-source software under AGPL-3.0. The first hour is charged at launch, each further hour when the previous one is used up, and unused seconds are refunded when you stop. Pricing has the details.
My rule for Forge on a cloud GPU: Forge Neo, built from its own Dockerfile on the Bare Metal template, published on 127.0.0.1 and reached through an SSH tunnel, with outputs copied off before every stop. If you do not need the AUTOMATIC1111 interface, the ComfyUI template gets you generating with fewer steps.
Launch an Ubuntu GPU VM on an RTX A6000