Self-Hosted AI Part 1 -- Untethered Creativity with Imaginer

The Radeon VII Story

One of my all-time favorite pieces of hardware has to be the Radeon VII. I remember being super excited about it back in the day. As a Linux and gaming enthusiast around that time, it was clear that AMD offered an easier path to good support, especially with what Steam had been cooking up with Proton. It had 16 GB of this fancy new HBM2 memory that seemed like it would be lightning fast and useful for a long time. It punched well above its weight, no doubt. It made Linux my only PC gaming machine and delivered dozens of hours of Dead or Alive 6 play sessions back in 2019. Today in 2026 it handles very different tasks.

The Radeon VII is also an absolute powerhouse for running Stable Diffusion with ROCm support on Linux. Those same 16 GB of HBM2 that made gaming fast now feed image generation workloads that need serious VRAM. If you have a Vega series card or older AMD hardware gathering dust somewhere, this post shows how to turn it into a self-hosted Stable Diffusion server and generate AI art from your phone through a local network connection.

The major proprietary AI tools have their place and I use them just like millions of other people do, but each interaction comes with costs: a loss of privacy every time you send a prompt to someone else’s servers, filters that shape what the model will or will not produce, and always the question of how those companies actually use your data. Centralized AI creates a bottleneck where one company controls access and shapes output according to its priorities. I prefer running my own models on my own hardware, keeping everything local and under my control at every step.

This series shows how to find that old Radeon VII sitting in your self-built steam machine and put it to actual use: running Stable Diffusion as a background service on your home server while triggering image generation from the Imaginer client app – whether you are on your couch or miles away through a VPN connection back to your home network.

Architecture Overview

The server acts as the brains of the operation. What you need is a Linux system capable of running Stable Diffusion WebUI with GPU acceleration. The AUTOMATIC1111 implementation runs great both headless in the background and locally, and we will configure it for both modes: web access on a local network and API-only mode specifically for use with Imaginer.

Imaginer sits on the client side and connects to our server while doing minimal work itself. It is available on Flathub or directly from GitHub, and features an Adwaita user interface that looks great across Linux desktop, tablet, and phone form factors. The client-side requirements are so low that it runs comfortably even on my FuriLabs FLX1s with a VPN tunnel back to the home server – which means image generation happens entirely on the beefy hardware while you interact through anything from your couch to anywhere on mobile data.

Security Note

Do not expose this port publicly. Keep a firewall between your machine and the open internet. Access it locally over your network or set up WireGuard/OpenVPN for remote connections, which I will cover in a future guide.

Hardware Requirements

Before downloading gigabytes of models, check your GPU:

If you meet these requirements, proceed with this guide. If not, the concepts still apply – you can use Imaginer with an external API provider instead, which falls outside the scope of this post.

Server Setup: Stable Diffusion WebUI

Step 1: Prerequisites

Install git, python, and wget on your Linux machine of choice (Nobara, Fedora, Ubuntu – your pick). Then clone the repository:

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
cd stable-diffusion-webui

Step 2: Run the Installer

Execute the provided installation script. It will set up Python, pip install all necessary packages into a virtual environment, and download the base model if everything goes smoothly. For NVIDIA users this process should complete without issues because CUDA support baked into most AI tooling makes the path forward much simpler. AMD ROCm requires an additional layer of configuration. Modern RDNA 2 and RDNA 3 cards work well out of the box, but legacy Vega 20 and Radeon VII demand manual intervention since they fall outside normal ROCm support ranges.

Step 3: The Executable Stack Hurdle (Nobara/Fedora)

Newer distros have stricter security around executable stack segments in shared libraries. glibc 2.42+ will block loading any library that marks its stack page as executable, and certain ROCm binaries still carry that flag from older development cycles. The fix involves patchelf to clear the execstack flag from specific libraries during installation:

# Install patchelf first
sudo dnf install patchelf

# Strip the flag from ROCm libraries in the venv
find venv/ -type f \( -name "libhiprtc.so" -o -name "libamdhip64.so" \) -exec patchelf --clear-execstack {} \;

Once this step completes, the system successfully loads those libraries without throwing permission errors.

Step 4: The AMD Override (Legacy Cards Only)

If you run a Vega 20 or Radeon VII like mine, there is an additional hurdle for getting AI software to recognize older architectures that AMD dropped support for. Set an environment variable override to force ROCm to load legacy architecture profiles during model initialization. You will use this same configuration when setting up the service file later:

export HSA_OVERRIDE_GFX_VERSION=9.0.6

\You also need to adjust precision flags by adding --precision full --no-half to prevent black image bugs on older Vega cards. These flags increase memory demands significantly, so you may be forced to use smaller models with reduced VRAM headroom. The trade-off is tolerable: slightly slower generations in exchange for actually getting working output from hardware that technically should no longer work at all.

Configuring Headless Mode

Running Stable Diffusion only when a Terminal window stays open works fine locally, but not as a proper background service. There are two pieces needed for headless access on Linux: command-line arguments in the user configuration script and a systemd user-level service file to manage the process without root privileges.

The webui-user.sh Configuration

Add these exports near the top of webui-user.sh or set them as shell profile variables:

export COMMANDLINE_ARGS="--listen --api --precision full --no-half --no-half-vae"
export HSA_OVERRIDE_GFX_VERSION=9.0.6

The --listen flag allows external connections on the local network, and --api enables the programmatic API that our client tool (Imaginer) will use to send generation requests. The precision and VAE flags protect against floating-point errors specific to older hardware like the Vega 20 architecture.

The systemd User Service

A user-level service manages Stable Diffusion without requiring root access, survives login session terminations, and restarts automatically on failure:

[Unit]
Description=Stable Diffusion WebUI API
After=network.target

[Service]
Type=simple
WorkingDirectory=%h/stable-diffusion-webui
ExecStart=/usr/bin/bash %h/stable-diffusion-webui/webui.sh
Restart=always

[Install]
WantedBy=default.target

Save this file as ~/.config/systemd/user/sdwebui.service, then run:

systemctl --user daemon-reload
systemctl --user enable --now sdwebui

Critical extra step: Enable linger so your systemd user services continue running after you log out or disconnect from SSH. Without it, the entire user service environment dies when you close a terminal window, and no amount of Restart=always saves it:

sudo loginctl enable-linger $USER

Server Defaults for Mobile-Friendly Output

Imaginer provides a minimal interface with limited settings available. This means getting good generation quality starts at the server level through defaults that shape output before Imaginer even makes a request. The web UI configuration file is where we lock in quality settings:

These settings live in ui-config.json inside the extensions folder of your WebUI installation directory.

Licensing Note Before Picking Models

Before downloading any models, keep licensing in mind:

DreamShaper works beautifully on the Radeon VII and ROCm setup we are building here, so I am going with that path through this guide. Choose based on what matches your intended use rather than performance benchmarks, because both paths deliver capable models on 16 GB VRAM hardware.

Getting Imaginer Running (The Client Side)

Imaginer is available as a Flatpak from Flathub or directly from the GitHub releases page. The client side does not need GPU acceleration at all since all heavy lifting happens over the network connection back to Stable Diffusion WebUI on your home machine:

# Via Flatpak recommended for broad compatibility:
flatpak install flathub com.github.ttt4bwt.imaginer

# Or grab the AppImage from GitHub if preferred:
# https://github.com/ttt4bwt/imaginer/releases

Once installed, open Imaginer preferences and configure a new provider connection pointing at your server. You will need:

  1. Server address. Find this by running ip -br a on the machine hosting WebUI. The local IP (usually 192.168.x.x) is what you want here.
  2. Port: Port 7860 is where the API listens.
  3. Provider settings: Imaginer lets you configure model parameters, sampler selection, and steps from the client side if you prefer more control than the server defaults provide.

If you are using a firewall on your server machine, ensure port 7860/tcp is allowlisted for local network traffic:

sudo firewall-cmd --add-port=7860/tcp --permanent
sudo firewall-cmd --reload

Seeing Results

Everything configured and connected. Time to generate something. I went with a simple prompt to test the whole pipeline end to end without complications: “A linux tux penguin planting a flower into a pile of dirt.” The image renders on the old Radeon VII, streams through the API over the local network, and lands in Imaginer on my phone screen within seconds.

From here, you can adjust your prompt for sharper detail, experiment with different checkpoint models once you confirm the pipeline works reliably, or refine settings like resolution and steps to improve output quality further.

What This Delivers

A stable, self-hosted image generation pipeline that gives you something no cloud service can match: total sovereignty from GPU silicon to app on your phone. No prompt filtering, no usage limits, no company deciding what art you should or should not be able to create. Open-source models, open-source software, running entirely on hardware you own at every step of the process.

This is a meaningful shift in how you interact with AI art tools: instead of submitting requests to external services controlled by others and subject to their terms, policies, and pricing changes, the infrastructure lives on your machine behind your firewall communicating only across connections you initiate through clients you selected. That is self-hosted AI at its most practical: powerful enough for real image generation work without becoming a full-time sysadmin project consuming all your time.

Stay tuned – this series continues by expanding the setup to include local LLM serving and other AI workloads that benefit from having everything run behind that same firewall on the same reliable hardware.