Opening application to network

[adrian-purnama]

Hi, I've successfully built and started OpenWA on Ubuntu. Initially the container was only exposed as 127.0.0.1:2785->2785/tcp, so I made some code changes and was able to expose it to my local network (http://192.x.x.x:2785).

However, I'm now running into an issue where OpenWA appears to be validating or redirecting against an HTTPS origin (e.g. https://192.x.x.x) while I'm accessing it over plain HTTP (http://192.x.x.x). This causes requests to be rejected, and I suspect it may be related to Helmet, CSP, HSTS, origin validation, or another security middleware.

What is the recommended way to expose OpenWA to other devices on a local network? Is there a supported configuration for binding to 0.0.0.0 and allowing HTTP access on private networks, or should it always be deployed behind a reverse proxy with HTTPS?

Also, would it be possible to provide OpenWA as a fully self-contained Docker image so deployment can be as simple as:

services:
  openwa:
    image: openwa/openwa:latest
    ports:
      - "2785:2785"

This would greatly simplify server deployments by removing the need to clone the repository, build locally, or run from a specific directory. Is there an official image available, or are there plans to support this deployment model?

[rmyndharis]

Hi @adrian-purnama — both of your questions have answers, so let me lay them out.

1. Pre-built Docker image

This has been available since very early on — every release tag going back to v0.1.1 publishes a multi-arch image (linux/amd64 + linux/arm64) to GHCR:

docker pull ghcr.io/rmyndharis/openwa:latest   # or a specific tag like :0.10.2

A minimal one-liner deploy looks exactly like what you sketched:

services:
  openwa:
    image: ghcr.io/rmyndharis/openwa:latest
    ports:
      - "2785:2785"
    volumes:
      - ./data:/app/data
    restart: unless-stopped

So you do not need to clone the repo and build locally — that's just an alternative documented in the Quick Start for users who want to hack on the source. The compose files in the repo do bind-mount ./data and forward a bunch of tunable envs, but the underlying image is the same one you'd pull from the registry.

Tags follow semver: :latest, :0.10, :0.10.2, etc.

2. Exposing OpenWA to your local network

Two pieces here:

(a) Bind to the network interface

By default the bundled compose binds to 127.0.0.1 only (a safety default). To reach it from another host on your LAN, set BIND_HOST=0.0.0.0 in your .env:

# .env
BIND_HOST=0.0.0.0

Or, with a hand-rolled docker run / compose like the snippet above, just exposing ports: ["2785:2785"] already binds to all interfaces — that's the default Docker behaviour.

(b) The HTTPS-upgrade trap you hit

What you described (browser forcing https://... over your plain-HTTP access) is not a bug — it's the production Content-Security-Policy including upgrade-insecure-requests, a security default that silently rewrites every HTTP sub-resource to HTTPS. On a direct plain-HTTP LAN deployment the server can't complete the TLS handshake, the dashboard JS never loads, and you get a blank screen.

There's a built-in opt-out for exactly this case. In the same .env:

CSP_UPGRADE_INSECURE_REQUESTS=false

That disables the directive (only do this on a trusted private network you control). The bundled compose files already forward this var, so a docker compose up -d after setting it will pick it up.

Recommended production posture

For anything beyond a trusted LAN, the safer pattern is to keep OpenWA bound to localhost and put a reverse proxy (Caddy / Traefik / Nginx / Coolify) in front of it that terminates TLS. We have a step-by-step guide in docs/12-troubleshooting-faq.md that covers Traefik and Coolify specifically — worth a read before going live.

Hope that unblocks you!