Embed image code

Good catch doing a sanity pass before we keep bashing at settings. Let’s untangle the pieces.

1. Docker + OpenWebUI 1.0 – are you forced to use Docker?

No, you’re not hard-locked into Docker forever.

OpenWebUI can run:

• In Docker (what you have now)
• Directly on the host with pip/uv / bare-metal install

The 1.0 docs push the Docker route because it’s clean and portable, but under the hood it’s just a Python app + a little frontend. So if you really want:

• Ougway (host) running OpenWebUI without Docker
• Still using your existing HTTPS front (Caddy)
• Talking out to maindesk over HTTP

That’s totally doable; it’s just a bit of migration work. We don’t have to do it right this second, but yes: running it non-Docker on Ougway is absolutely an option.

2. HTTPS on OpenWebUI ⇄ HTTP on Stable Diffusion – is that a problem?

Short answer: No, not for what you’re doing.

Here’s why:

• Your browser talks to OpenWebUI over HTTPS (through Caddy).
• The OpenWebUI backend (inside Docker) talks to Stable Diffusion on maindesk over HTTP on the LAN:
  http://192.168.254.14:7860.

Those are two separate connections:

• Browser ⇄ (HTTPS) ⇄ Ougway / Caddy / OpenWebUI
• OpenWebUI backend ⇄ (HTTP) ⇄ maindesk / A1111

The browser never directly calls the Stable Diffusion API, so there is no mixed-content issue from the browser’s point of view. It just sees one HTTPS site (OpenWebUI). All A1111 traffic happens server-side inside OpenWebUI.

So:
– No cert on maindesk is fine.
– HTTPS on Ougway doesn’t block this setup.

The only time HTTPS vs HTTP becomes a real blocker is if:

• JavaScript in the browser tries to call http://192.168.254.14:7860 directly from a https:// page → then you get mixed-content errors. But that’s not how the A1111 integration is designed; it’s the backend doing the calls.

3. So what’s actually biting us?

Likely one (or both) of:

1. OpenWebUI’s A1111 integration + Docker networking weirdness
   Inside Docker, “localhost” is the container, not the host. But you’re already using the LAN IP (192.168.254.14), and curl from Ougway’s host works, so this is probably fine.

2. OpenWebUI 1.0’s validator / UI bug with the “model” field
   The error you saw (Invalid URL '/sdapi/v1/sd-models': No scheme supplied) is OpenWebUI complaining about its own internal base URL, not about TLS. It means at some point that field was blank or malformed, so it tried to call '/sdapi/v1/sd-models' instead of 'http://192.168.254.14:7860/sdapi/v1/sd-models'.

The TLS/HTTPS on Ougway is not the thing breaking this. The evidence:

• curl http://192.168.254.14:7860/sdapi/v1/sd-models from Ougway works.
• You can hit http://192.168.254.14:7860 in browser.
• Only OpenWebUI’s internal validator is whining.

4. Strategic options from here

You’ve got two realistic paths:

Option A – Stick with Docker OpenWebUI and beat its A1111 UI into submission

• We clean its config (delete the broken A1111 backend entry, re-add from scratch).
• Set:
• Base URL: http://192.168.254.14:7860
• Model: Stable-diffusion_sd_xl_base_1.0 (from the JSON you saw)
• If the dropdown never populates, we type the model name manually and see if image calls actually work, ignoring the “valid/invalid” badge.

Option B – Say “screw Docker,” install OpenWebUI directly on Ougway

• Stop the Docker container.
• Install OpenWebUI on the host (Python/uv route).
• Point Caddy at the local OpenWebUI port.
• Configure A1111 exactly the same way (http://192.168.254.14:7860).
• Now everything (OpenWebUI + LLaMA + network) lives at host level, no container networking quirks.

If you already hate Docker and this is the first major integration you’re trying, I’d lean toward Option B in the medium term – it matches how you run the rest of Ougway, and it will make future wiring (tools, scripts, logging) less annoying.

We don’t have to rip it out this second, but:

• HTTPS vs HTTP is not your blocker.
• Docker + OpenWebUI’s evolving A1111 integration UI is a pain vector.

If you want, next step we can do is either:

• Go: “Let’s uninstall the Docker OpenWebUI and put 1.0 bare-metal on Ougway,”
  and I’ll give you the exact install sequence.

or

• Say: “Let’s try one last time to get A1111 working through Docker OpenWebUI 1.0,”
  and I’ll walk you through a config reset and a minimal test that ignores the fancy dropdowns and just checks whether it can fire one actual image job.

Right, so two separate threads here:

1. HTTPS vs HTTP between Ougway and maindesk – not your blocker.
2. Docker + OpenWebUI’s cranky A1111 integration – is the real pain.

Let me give you a concrete path forward instead of more wrestling.

1️⃣ HTTPS + non-cert box: are we okay?

Yep.

• Browser ⇄ HTTPS ⇄ Ougway/OpenWebUI (behind Caddy)
• OpenWebUI backend (inside Docker) ⇄ HTTP ⇄ maindesk/A1111

Those are two independent connections:

• The browser never talks directly to 192.168.254.14:7860, so there’s no mixed-content issue.
• The HTTP call to A1111 is from backend code, not from a web page, so it doesn’t care about TLS at all.

So:
A cert on Ougway and no cert on maindesk is totally fine.
We do not need to wrap A1111 in HTTPS just to talk from OpenWebUI.

2️⃣ The real problem: Docker OpenWebUI 1.0 being fussy

Given:

• You hate Docker.
• You’re already doing everything else bare-metal.
• We’ve confirmed the A1111 API is good (curl works).
• The only thing misbehaving is OpenWebUI’s validation / UI (model field, invalid URL errors).

My recommendation:

> Stop fighting Docker’s networking + that 1.0 integration UI and just move OpenWebUI onto the host.

That gives you:

• Normal file paths.
• Normal networking (no container IP weirdness).
• Easier future scripting/tools.
• Still fronted by Caddy for HTTPS, same as now.

3️⃣ Concrete next move: plan the migration

You said you don’t want to have to do Docker on this side – so here’s the practical sequence I’d use (no need to run it this second, just outlining):

1. Leave the Docker OpenWebUI running for now (so you don’t lose anything yet).
2. Install a bare-metal OpenWebUI 1.x on Ougway:
   – Create a Python venv.
   – Install OpenWebUI with pip/uv or their bare-metal script.
   – Run it on a local port (e.g. http://127.0.0.1:8080).
3. Point Caddy at the new local port instead of the Docker container.
4. Verify:
   – You can hit OpenWebUI over HTTPS as before.
   – It can hit http://192.168.254.14:7860 (same curl test, but from the new environment).
5. Once you’re happy, shut down the Docker container and forget about it.

Then we re-do the A1111 integration in that clean environment, where:

• No Docker networking oddities.
• Config files are just on disk you can edit.
• If the UI still misbehaves, we can literally edit the JSON/YAML for the integration by hand and bypass the buggy form.

If you’d rather *