Perfect, fresh window, clean brain. Let’s wire this up properly.

Here’s step 1 in a tight, no-nonsense sequence, including the exact commands you asked for.

---

1️⃣ From Ougway: confirm the A1111 API is actually reachable

> Assumptions:
> • A1111 is running on maindesk with --listen --api (or equivalent “allow remote” enabled).
> • Port is the default 7860.
> • Ougway and maindesk are on the same LAN.

1.1. Get/confirm maindesk’s IP (if you don’t already know it)

On maindesk (just once):

ip addr | grep 'inet ' | grep -v '127.0.0.1'

Pick the LAN IP, e.g. 192.168.1.50.
I’ll call that MAINDESK_IP below.

---

1.2. From Ougway, test basic connectivity

In a terminal on Ougway:

ping -c 3 MAINDESK_IP

Example:

ping -c 3 192.168.1.50

• If you get replies: network path is good.
• If not: we’ve got a LAN / firewall / interface issue to solve first.

---

1.3. From Ougway, curl the A1111 API directly

Still on Ougway:

curl http://MAINDESK_IP:7860/sdapi/v1/sd-models

Example:

curl http://192.168.1.50:7860/sdapi/v1/sd-models

What you should see if A1111 API is up:

• A blob of JSON describing your models, e.g. [{"title": ...}, ...]
• If you have jq installed, you can pretty-print:

bash
curl -s http://192.168.1.50:7860/sdapi/v1/sd-models | jq '.[].title'

Common failure cases:

• Connection refused
  → A1111 not running, or not listening on that IP/port.

• Connection timed out
  → Routing / firewall problem between Ougway and maindesk.

• curl: (7) Failed to connect to ...
  → Same as above; A1111 not reachable.

Important:
Make sure you’re using http://, not https://.
The A1111 API is plain HTTP on the LAN. Using https here will just confuse everything.

---

1.4. If curl fails: fix A1111 launch on maindesk

On maindesk, in your A1111 folder, make sure you’re launching with something like:

./webui.sh --listen --api

Or if you use COMMANDLINE_ARGS in webui-user.sh:

COMMANDLINE_ARGS="--listen --api"

Then restart A1111 and re-run on Ougway:

curl http://192.168.1.50:7860/sdapi/v1/sd-models

Once that works, we know for sure the A1111 API is alive and reachable from Ougway, and we can safely move to step 2 (pointing OpenWebUI at http://192.168.1.50:7860 instead of the broken /sdapi/v1/sd-models style URL that gave you the “No scheme supplied” error).

If you tell me what curl returns (or the exact error line), I’ll jump straight into step 2 and wire OpenWebUI to it.

Yeah, I’m with you: if Docker is fighting you and you don’t need it, kill it with fire and run OpenWebUI native.

Let’s do exactly that in a clean, linear sequence on LittleOugway (Ubuntu).

---

1️⃣ Stop and remove the Docker OpenWebUI

On LittleOugway:

sudo docker ps

Find the OpenWebUI container name (likely open-webui).

Then:

# Stop and remove the container
sudo docker stop open-webui
sudo docker rm open-webui

# (Optional) remove the image(s) too
sudo docker images | grep open-webui
sudo docker rmi ghcr.io/open-webui/open-webui:cuda ghcr.io/open-webui/open-webui:main 2>/dev/null

If any of those rmi commands complain “image not found”, ignore it and move on.

---

2️⃣ (Optional but per your wishes) Nuke Docker itself

If you truly want Docker gone:

# Stop and disable Docker
sudo systemctl stop docker
sudo systemctl disable docker

Then remove packages (most common on Ubuntu):

sudo apt purge -y docker.io docker-compose-plugin

If you installed docker-ce from Docker’s repo, also:

sudo apt purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Finally, remove leftover data:

sudo rm -rf /var/lib/docker

At this point, OpenWebUI-in-Docker is dead and Docker itself is either disabled or gone.

---

3️⃣ Install OpenWebUI bare metal with Python (no container)

Still on LittleOugway:

3.1. Make sure Python tools are there

sudo apt update
sudo apt install -y python3-venv python3-pip

3.2. Create a dedicated app directory + venv

mkdir -p ~/apps/openwebui
cd ~/apps/openwebui

python3 -m venv venv
source venv/bin/activate

Your prompt should now show (venv).

3.3. Install OpenWebUI (and recommended extras)

pip install -U pip
pip install -U open-webui
pip install -U Pillow pyopenssl

(This follows the current docs for the pip install path. citeturn1search0turn1search7)

---

4️⃣ Test-run OpenWebUI directly

From the same (venv):

open-webui serve --host 0.0.0.0 --port 8080

• By default, open-webui serve binds to 0.0.0.0 and port 8080, so technically you can omit the flags, but this makes it explicit. citeturn2search2turn2search3
• Watch the logs until you see something like:

text
Uvicorn running on http://0.0.0.0:8080

Now, from LittleOugway’s browser, open:

http://localhost:8080

If that page loads, congrats — you’ve got a non-Docker OpenWebUI running.

Hit Ctrl+C to stop it when you’re satisfied; we’ll daemonize it next.

---

5️⃣ (Optional but nice) Create a systemd service for OpenWebUI

So you don’t have to manually activate the venv every time, we’ll create a simple service that runs it.

Still on LittleOugway:

5.1. Find your full paths

From inside ~/apps/openwebui:

pwd
which python
which open-webui

For example, you’ll likely see something like:

• Project dir: /home/darren/apps/openwebui
• Python: /home/darren/apps/openwebui/venv/bin/python
• OpenWebUI: /home/darren/apps/openwebui/venv/bin/open-webui

We’ll use those in the service file.

5.2. Create /etc/systemd/system/openwebui.service

sudo nano /etc/systemd/system/openwebui.service

Put this in (edit paths if yours differ):

[Unit]
Description=Open WebUI (bare metal)
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/darren/apps/openwebui
ExecStart=/home/darren/apps/openwebui/venv/bin/open-webui serve --host 0.0.0.0 --port 8080
Restart=on-failure
User=darren
Group=darren
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

Save and exit.

5.3. Enable and start

sudo systemctl daemon-reload
sudo systemctl enable openwebui
sudo systemctl start openwebui
sudo systemctl status openwebui

You should see active (running).

Now http://ougway.local:8080 or http://<Ougway_IP>:8080 should give you OpenWebUI, no Docker anywhere in sight.

---

6️⃣ Point OpenWebUI (bare metal) to A1111 on maindesk

Now the fun bit: no more container networking nonsense.

1. Make sure on maindesk you are still running:

bash
./webui.sh --listen --api
or it’s equivalent, with --listen --api in COMMANDLINE_ARGS.

2. Confirm from LittleOugway (host, not container anymore) that you can see models:

bash
curl http://MAINDESK_IP:7860/sdapi/v1/sd-models

You’ve already done this, but now this exact path is what OpenWebUI will call too.

3. In OpenWebUI (bare metal) UI on LittleOugway:
   – Go to Settings → Image / Stable Diffusion (or “Image Generation”) provider.
   – Choose the “Automatic1111 / SD WebUI” or equivalent provider.
   – Set the base URL to:

   text
http://MAINDESK_IP:7860

• Save / test.

Because we’re now on the host itself, not inside a container, that URL will be reachable exactly like your curl test — and the model dropdown should auto-populate. If it doesn’t, the problem is now strictly between OpenWebUI and A1111, not Docker, and we can debug that cleanly.

---

If you want, the next step after this is working is we can bolt Caddy/HTTPS back in front of this native OpenWebUI so your mic features are happy again — but first priority is: no Docker, native OpenWebUI, A1111 models visible.

Nice, that’s exactly what I needed to see. Container is called openwebui. Let’s kill it and move you to bare-metal.

I’ll keep this to copy-paste blocks.

---

1️⃣ Stop and remove the Docker OpenWebUI

On Ougway:

sudo docker stop openwebui
sudo docker rm openwebui

You can confirm it’s gone with:

sudo docker ps

(Should now show no openwebui line.)

If you want Docker itself gone too (your earlier “dismantle Docker and get the fuck rid of it”):

sudo systemctl stop docker
sudo systemctl disable docker
sudo apt purge -y docker.io docker-compose-plugin docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo rm -rf /var/lib/docker

Ignore any “package not installed” warnings; they’re fine.

---

2️⃣ Create a bare-metal OpenWebUI install

2.1. Prep directory + venv

mkdir -p ~/apps/openwebui
cd ~/apps/openwebui

sudo apt update
sudo apt install -y python3-venv python3-pip

python3 -m venv venv
source venv/bin/activate

You should now see (venv) in your prompt.

2.2. Install OpenWebUI into that venv

pip install -U pip
pip install -U open-webui

(If it complains about rust or build tools, tell me the error; we’ll add whatever package is missing.)

---

3️⃣ Test run OpenWebUI (no Docker)

Still in ~/apps/openwebui with (venv) active:

open-webui serve --host 0.0.0.0 --port 8080

Wait for the “Uvicorn running on…” line, then in a browser on Ougway go to:

http://localhost:8080

If the UI loads: success — you now have native OpenWebUI.

Hit Ctrl+C in the terminal to stop it when you’re done testing.

---

4️⃣ Wire it to A1111 on maindesk

You’ve already confirmed from Ougway that:

curl http://MAINDESK_IP:7860/sdapi/v1/sd-models

returns JSON.

So in the new OpenWebUI (http://ougway:8080):

1. Go to Settings → Image / Stable Diffusion provider.
2. Choose the Automatic1111 / SD WebUI option.
3. Set the base URL to:

text
http://MAINDESK_IP:7860

4. Save, then check if the model dropdown populates.

---

5️⃣ (Optional) Make it a service later

Once we know the bare-metal setup + A1111 hookup is solid, I’ll give you the openwebui.service systemd file so it auto-starts on boot.

For now, run through steps 1–4 and paste back:

• Any errors from pip install -U open-webui, or
• Anything weird from open-webui serve logs, or
• Whether the model list finally auto-fills.

Nice, that error actually tells us exactly what’s going on.

> TL;DR: The open-webui PyPI package now requires Python ≥ 3.11, but your venv is using Python 3.10, so pip can’t find a compatible version.

We’ll fix this by:

1. Installing Python 3.11 on Ougway
2. Recreating the venv with Python 3.11
3. Installing open-webui again

I’ll keep it tight and linear.

---

1️⃣ Install Python 3.11 + venv support

On Ougway:

sudo apt update
sudo apt install -y python3.11 python3.11-venv

You can verify it exists with:

python3.11 --version

You should see something like Python 3.11.x.

---

2️⃣ Recreate the venv using Python 3.11

You currently have a venv using 3.10. Let’s blow it away and recreate it.

From ~/apps/openwebui:

# Make sure you’re in that directory
cd ~/apps/openwebui

# If venv is active, deactivate it
deactivate 2>/dev/null || true

# Remove the old 3.10 venv
rm -rf venv

# Create a new venv using Python 3.11
python3.11 -m venv venv

# Activate it
source venv/bin/activate

Double-check which Python the venv is using:

python --version

You want it to say Python 3.11.x.

---

3️⃣ Install OpenWebUI into the new venv

With the 3.11 venv active ((venv) in the prompt):

pip install -U pip
pip install -U open-webui

This time, pip should not complain about Python version and should actually install open-webui.

If it finishes without error, test-run:

open-webui serve --host 0.0.0.0 --port 8080

Then in a browser on Ougway:

http://localhost:8080

If that comes up, we’re golden: native OpenWebUI, Python 3.11, no Docker.

---

If any of those commands throw a fresh error (especially the pip install -U open-webui or the open-webui serve line), paste that chunk and we’ll fix the next bottleneck.

Yes — that makes a BIG difference.
PyEnv (or “pyenvironment” as you called it earlier — same thing) completely overrides which versions of Python exist on your system and which versions your virtualenvs can see.

Right now, the blocker is:

❗ Your current venv is using Python 3.10 because pyenv’s shims say 3.10 is “the global/system version.”

OpenWebUI requires Python ≥ 3.11, so the installation fails.

We just need to update pyenv’s available versions and set the correct one.

I’ll give you the exact PyEnv path.

---

✅ Clean sequence to fix PyEnv + get Python 3.11 working

1️⃣ Check what PyEnv thinks is installed

Run:

pyenv versions

You'll see something like:

* system (3.10.x)
  3.11.x (maybe)

If you don’t see a 3.11 version, then pyenv never installed it.

---

2️⃣ Install Python 3.11 through PyEnv (not apt)

(This is the correct way when pyenv manages your Python stack.)

Run:

pyenv install 3.11.9

Or list available 3.11 versions:

pyenv install -l | grep 3.11

Pick the latest 3.11.x.

This will take a few minutes.

If you get build errors (openssl, zlib, readline), tell me — I’ll give you the exact Ubuntu package list.

---

3️⃣ Make Python 3.11 the local version for OpenWebUI

Go to your openwebui directory:

cd ~/apps/openwebui

Then tell PyEnv:

pyenv local 3.11.9

Now verify:

python --version

Should say:

Python 3.11.9

This is the key step — without this, every venv you make will still default to 3.10.

---

4️⃣ Recreate the venv with PyEnv’s new Python 3.11

rm -rf venv
python -m venv venv
source venv/bin/activate

Check inside venv:

python --version

Should say 3.11.x now.

---

5️⃣ Install OpenWebUI again

pip install -U pip
pip install -U open-webui

This time it WILL install because Python 3.11 is in use.

---

6️⃣ Test-run

open-webui serve --host 0.0.0.0 --port 8080

If you see Uvicorn startup lines, it worked.

---

❗ Before we proceed:

Please paste the output of:

pyenv versions

That will tell me what 3.11 versions, if any, pyenv thinks you have — and I’ll tailor the rest exactly.

Paste that result and we continue.

Right, this is exactly the pyenv + venv trap.

What’s happening:

• You’re inside an old venv that was created with 3.10, so:
• python in there will always be 3.10.x, no matter what you do with pyenv local.
• pyenv local 3.11.9 only affects new shells / non-venv python calls.

So we need to:

1. Get out of the old venv
2. Make sure pyenv is using 3.11.9 in this dir
3. Recreate the venv with that 3.11.9

Here’s the exact sequence — just run it top to bottom.

---

1️⃣ Leave the old venv

From anywhere:

deactivate 2>/dev/null || true

Your prompt should no longer start with (venv).

---

2️⃣ Make sure pyenv has Python 3.11.9 and set it locally

Now:

cd ~/apps/openwebui

# See what pyenv knows about
pyenv versions

If you don’t see 3.11.9 in that list, install it:

pyenv install 3.11.9

(If this errors about missing libs, stop and paste that error later; for now just follow the flow.)

Then set it as the local Python for this project:

pyenv local 3.11.9

Confirm:

python --version

This one should now say Python 3.11.9 (or whatever 3.11.x you installed).
If it still says 3.10.x here, then either pyenv isn’t hooked into your shell, or pyenv local didn’t take; but assuming your earlier pyenv local ran, this should now work.

---

3️⃣ Recreate the venv with Python 3.11

Now we nuke the old 3.10 venv and recreate it under 3.11:

rm -rf venv
python -m venv venv
source venv/bin/activate

Check inside venv:

python --version

This must now say Python 3.11.x.
If it does, we’re finally on the right interpreter.

---

4️⃣ Install OpenWebUI

With the new (venv) active:

pip install -U pip
pip install -U open-webui

This time it should not complain about “requires Python >=3.11”.

---

5️⃣ Test run

Still in ~/apps/openwebui:

open-webui serve --host 0.0.0.0 --port 8080

Then hit:

http://localhost:8080

in a browser on Ougway.

If you get that far, we’ve got:

• No Docker
• Native OpenWebUI
• Correct Python version

From there we can wire it back to A1111 and then, if you want, put Caddy/HTTPS in front of it again.

Nice, that’s progress: bare-metal OpenWebUI is up, and the LLM side looks healthy. 🎉
Now we just need to get A1111’s API talking to it. The key bit:

> Being able to open the SD web page at
> http://192.168.254.14:7860/
> does not guarantee the /sdapi/... API is enabled.

OpenWebUI doesn’t talk to the pretty web UI; it talks to the JSON API at /sdapi/v1/sd-models. If that endpoint isn’t live, OWUI will say “invalid connection” and won’t populate models.

Let’s pin this down step-by-step.

---

1️⃣ Make sure A1111 API is actually enabled

On maindesk (where A1111 runs), you want it launched with --api and --listen.

Option A – via webui-user.sh (recommended)

In your A1111 install directory on maindesk:

nano webui-user.sh

Look for COMMANDLINE_ARGS= and set it something like:

COMMANDLINE_ARGS="--listen --api --xformers"

(Keep any other flags you like, just make sure --api and --listen are there.)

Save, exit, then restart A1111:

./webui.sh

Let it fully start up.

---

2️⃣ From Ougway: test the API endpoint directly

On Ougway, in a terminal:

curl -v http://192.168.254.14:7860/sdapi/v1/sd-models

What you want:

• Good case: you see JSON like [{"title":"some-model","model_name":"..."} ...]
• Bad cases:
• 404 Not Found with some HTML → API is not enabled.
• Connection refused / timeout → network/firewall/listen issue.
• Any TLS/HTTPS error → wrong scheme (must be http://, not https://).

Until this curl returns JSON, OpenWebUI will never be happy.

---

3️⃣ Double-check the OpenWebUI settings

In your new bare-metal OpenWebUI UI (http://ougway:8080):

1. Go to Settings → Image / Stable Diffusion / Automatic1111 (wording may vary slightly by version).
2. Make sure the provider is the Automatic1111 / SD WebUI option, not anything like “ComfyUI,” “OpenAI Images,” etc.
3. Set the Base URL to:

text
http://192.168.254.14:7860

• No /sdapi/v1/sd-models
• No trailing path beyond the port
• http, not https

4. Save, then hit whatever “Test” / “Refresh models” button is there (or just open the model dropdown).

If step 2’s curl returned JSON and step 3 is correct, the model list should populate.

---

4️⃣ If it still says “connection invalid”

Then the next thing to look at is the OpenWebUI server log.

From Ougway, where you start OWUI:

cd ~/apps/openwebui
source venv/bin/activate
open-webui serve --host 0.0.0.0 --port 8080

While you try to add the SD endpoint in the UI, watch the terminal. You’ll see an error like:

• ConnectionRefusedError
• ReadTimeout
• 404 Client Error
• or something similar

If you can, copy/paste that short error chunk here, and I can tell you exactly why OWUI is rejecting it.

---

But the absolute lynchpin is this:

> Does this return JSON or not?
> curl -v http://192.168.254.14:7860/sdapi/v1/sd-models

If it doesn’t, we fix A1111’s launch flags.
If it does, then we know the bug is purely on the OpenWebUI config side and we’ll adjust that.

Perfect, that curl output is exactly what we wanted:

• A1111 API is up
• From Ougway you get HTTP/1.1 200 OK and a clean JSON list of models from
  http://192.168.254.14:7860/sdapi/v1/sd-models

So: networking + A1111 are fine.
The only thing misbehaving now is OpenWebUI’s own validation UI.

Let’s just force-feed OpenWebUI the right config via env vars and let it save that internally, bypassing the picky “URL invalid” front-end check.

---

1️⃣ Wire A1111 into OpenWebUI via env vars

OpenWebUI supports env vars for A1111:

• AUTOMATIC1111_BASE_URL – the URL to the SD API (e.g. http://127.0.0.1:7860) citeturn8view1
• ENABLE_IMAGE_GENERATION – master switch for image gen citeturn8view1
• IMAGE_GENERATION_ENGINE – choose automatic1111 as the engine citeturn8view1

We’ll use those once, and because they’re PersistentConfig, OpenWebUI will store them in its own config and remember them on future runs. citeturn8view1

On Ougway:

cd ~/apps/openwebui
source venv/bin/activate

AUTOMATIC1111_BASE_URL=http://192.168.254.14:7860 \
ENABLE_IMAGE_GENERATION=True \
IMAGE_GENERATION_ENGINE=automatic1111 \
open-webui serve --host 0.0.0.0 --port 8080

Leave that running and open the UI at:

http://localhost:8080

Now:

• Go to Admin / Settings → Images
• You should see:
• Image generation enabled
• Engine set to Automatic1111
• Base URL pre-filled as http://192.168.254.14:7860 (even if the little “verify” button still whines, the backend config is in place)

---

2️⃣ Quick sanity check from the UI

In a chat:

1. Type a normal text prompt.
2. Use the “Generate Image” button/icon.
3. Watch what happens on the A1111 box:
   – You should see requests in its console.
   – Images should appear in the usual outputs folder on maindesk.

If images start appearing, then:

• OpenWebUI is successfully calling A1111,
• and the “URL invalid” message is just UI validation being fussy, not reality.

---

3️⃣ After first success: go back to a normal launch

Once you’ve confirmed it works at least once:

• Stop OpenWebUI (Ctrl+C in that terminal).
• From then on you can just run:

cd ~/apps/openwebui
source venv/bin/activate
open-webui serve --host 0.0.0.0 --port 8080

The stored config (AUTOMATIC1111 base URL, engine, image generation enabled) should persist without needing env vars again.

---

Bottom line:

• Your curl proves A1111 is healthy.
• We’ve now told OpenWebUI directly:
  “Use http://192.168.254.14:7860 as AUTOMATIC1111, engine = automatic1111, image gen = on.”
• If the UI still complains when you hit “verify,” ignore the nag and test actual image generation — that’s the real truth.

Yeah, that traceback is exactly the smoking gun we needed.

> MissingSchema: Invalid URL '/sdapi/v1/options': No scheme supplied. Perhaps you meant https:///sdapi/v1/options?

Translation:
OpenWebUI is trying to hit /sdapi/v1/options with no base URL, so requests chokes. Your curl test proves A1111 is fine:

curl -v http://192.168.254.14:7860/sdapi/v1/sd-models
# 200 OK with a nice JSON model list ✅

So the problem is inside OpenWebUI’s image backend, not the network or Stable Diffusion.

And yes: the IP I used earlier should be maindesk’s IP:
http://192.168.254.14:7860 — you’re correct there.

Let’s fix this in a tight, do-these-commands order and bypass the broken “verify” path.

---

1️⃣ Stop the current OpenWebUI process

In the terminal where it’s running in the venv:

Ctrl + C

Make sure it’s not running anymore.

---

2️⃣ Set the correct env vars for this shell

Still on Ougway, in your venv:

cd ~/apps/openwebui
source venv/bin/activate

Now export these (note: using .14, maindesk):

export ENABLE_PERSISTENT_CONFIG=False
export ENABLE_IMAGE_GENERATION=True
export IMAGE_GENERATION_ENGINE=automatic1111
export AUTOMATIC1111_BASE_URL=http://192.168.254.14:7860

Pick one of your models as default; from your curl output, e.g.:

export IMAGE_GENERATION_MODEL=Stable-diffusion_v1-5-pruned-emaonly

(That string is exactly the model_name field from the JSON.)

What this does:

• ENABLE_PERSISTENT_CONFIG=False → makes OpenWebUI obey the env vars instead of some half-broken stored config. citeturn18search0
• AUTOMATIC1111_BASE_URL now has a proper http://... base, so when it builds
  BASE_URL + "/sdapi/v1/options" it becomes
  http://192.168.254.14:7860/sdapi/v1/options instead of just /sdapi/v1/options.

---

3️⃣ Start OpenWebUI from that same shell

open-webui serve --host 0.0.0.0 --port 8080

Leave it running; watch the log for any new MissingSchema lines. You should not see that error now.

---

4️⃣ In the browser: use Automatic1111 without fighting the “verify” dialog

1. Open OpenWebUI on Ougway:
   http://ougway.local:8080 (or whatever you normally use).
2. Log in.
3. Go to User Settings → Images (or wherever they parked it in this version).
4. Set:
   – Engine: automatic1111
   – Model: if the dropdown now loads, pick Stable-diffusion_v1-5-pruned-emaonly
   If the dropdown still glitches, just type that exact string in.
5. Don’t stress about the “verify URL” button — the env vars already wired the backend.

Now start a chat, hit the little image icon / image tool and try a simple prompt:

> “A small copper torus floating over a starfield.”

If everything’s right, OpenWebUI will:

• Call http://192.168.254.14:7860/sdapi/v1/txt2img (or equivalent),
• A1111 will happily render using that model,
• You should see images show up in the chat.

---

5️⃣ If the UI still throws the same /sdapi/v1/options error

That means the stored config in data/webui.db still has an empty automatic1111_base_url and the specific “models list” endpoint is hitting that path before reading env.

Quick nuke-and-reset (for this new Python install only):

From another terminal:

cd ~/apps/openwebui
source venv/bin/activate

# optional: backup first
cp -a data/webui.db data/webui.db.bak-$(date +%F-%H%M)

# then remove it
rm data/webui.db

Then restart with the same env exports as in step 2 and:

open-webui serve --host 0.0.0.0 --port 8080

With ENABLE_PERSISTENT_CONFIG=False and a fresh DB, it will rebuild config using the env vars, so AUTOMATIC1111_BASE_URL will be non-empty from the very first run, and the models list calls should stop generating /sdapi/v1/options without a scheme.

---

6️⃣ (Optional once you’re happy) Kill Docker’s old OpenWebUI

When this native install is behaving and you’ve confirmed image gen works:

sudo docker stop openwebui
sudo docker rm openwebui

If you want to reclaim the old Docker volume too (and don’t care about the old data):

sudo docker volume ls | grep open-webui
sudo docker volume rm open-webui   # only if you’re sure

---

If you want, next step after this is: we can write a tiny start-openwebui.sh that does the exports and open-webui serve so you don’t have to remember the env vars by hand every time.

Ohhhh yes, that log + “it just sent a job and came back inline” is exactly what I wanted to hear. 🥳
You’ve now got bare-metal OpenWebUI 0.6.36 talking cleanly to A1111 on maindesk. Perfect.

Now: service cleanup / swap from Docker → native.

---

1️⃣ Kill / retire the old Docker-based OpenWebUI

On Ougway:

sudo docker ps

If you still see the old container:

sudo docker stop openwebui
sudo docker rm openwebui

(If it says “no such container”, you’re already clean here.)

If you previously had any systemd unit whose job was “start docker OpenWebUI on boot”, we don’t want that anymore.

Quick way to see what’s there:

systemctl list-unit-files | grep -i webui
systemctl list-unit-files | grep -i open

If you see something like openwebui.service or docker-openwebui.service that was tied to Docker:

sudo systemctl disable --now <that-service-name>

You can safely leave Docker itself installed for other stuff, or nuke it later if you really want it gone.

---

2️⃣ Create a new systemd service for the native OpenWebUI

You’re already starting it manually with:

cd ~/apps/openwebui
source venv/bin/activate
open-webui serve --host 0.0.0.0 --port 8080

We just capture that in a service so it runs on boot.

2.1. Make the unit file

sudo nano /etc/systemd/system/openwebui.service

Put this in (paths assume your current layout; adjust if different):

[Unit]
Description=Open WebUI (native, Python venv)
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/darren/apps/openwebui
# Env vars – optional, but nice to hard-wire the SD endpoint
Environment=AUTOMATIC1111_BASE_URL=http://192.168.254.14:7860
Environment=ENABLE_IMAGE_GENERATION=True
Environment=IMAGE_GENERATION_ENGINE=automatic1111
ExecStart=/home/darren/apps/openwebui/venv/bin/open-webui serve --host 0.0.0.0 --port 8080
Restart=on-failure
User=darren
Group=darren
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

Save and exit.

> If there was an older /etc/systemd/system/openwebui.service from the Docker setup, this will just overwrite it with the new, good one.

---

3️⃣ Enable and start the new service

sudo systemctl daemon-reload
sudo systemctl enable openwebui
sudo systemctl start openwebui
sudo systemctl status openwebui

You want to see:

• Loaded: loaded (/etc/systemd/system/openwebui.service; enabled; …)
• Active: active (running)

Now you can:

• Close your manual open-webui terminal.
• Hit your usual URL (whatever Caddy/HTTPS is fronting — likely https://ougway.local/ or similar) and you should land on the same 0.6.36 UI, backed by the venv instance, not Docker.

---

4️⃣ Sanity check: which one is actually listening?

Just to prove to yourself it’s the new one:

ps aux | grep open-webui | grep -v grep

You should see something like:

darren  ... /home/darren/apps/openwebui/venv/bin/python ... open-webui serve ...

and no docker/containerd process owning OpenWebUI.

---

If you want, next round we can tidy Caddy’s config so https://ougway.local (or your certed hostname) just reverse-proxies to http://127.0.0.1:8080 and you never think about ports again. But for the OpenWebUI/Docker crossover: you’re effectively done once that new openwebui.service is running and the old Docker bits are disabled.