Static asset URLs use absolute host:port causing 404 when binding to 0.0.0.0

[sternma]

Description

When running Textual-Serve bound to 0.0.0.0, the landing‐page template inlines all static asset URLs (CSS/JS/images) using the configured host or public_url. If you pass host="0.0.0.0" (or forget to set public_url), every request for /static/... goes to http://0.0.0.0:8000/static/..., which is not routable, and assets fail to load.

Steps to Reproduce

1. Install textual-serve==1.1.2 in a project.
2. Create a main.py containing:

   from textual_serve.server import Server
   
   server = Server("python3 your_app.py", host="0.0.0.0")
   server.serve(debug=True)

3. Run:

   python3 main.py

4. Open a browser to http://<your-machine-IP>:8000/.
5. Observe in DevTools → Network that requests for xterm.css, textual.js, etc. are targeting http://0.0.0.0:8000/static/... and failing.

Actual Behavior

• Asset requests are issued to 0.0.0.0:8000, which refuses connections.
• Landing page shows placeholder panel without styling or “Run ▶︎” button (static assets never load).

Expected Behavior

Assets should either:

1. Be served via relative URLs (e.g. /static/js/textual.js) so they load from the same origin the browser requested, or
2. If an absolute URL is required, fall back to using the incoming Host header when public_url is unset, rather than the bind address.

Environment

• textual-serve version: 1.1.2
• Python: 3.10.11
• Platform: Ubuntu 22.04 LTS (Docker container)
• Browser: Chrome 135.0.0.0 on macOS 10.15.7

Proposed Solution

Update the Jinja template (app_index.html) so that static assets use relative paths by default:

<!-- before -->
<link rel="stylesheet" href="{{ config.static.root }}/css/xterm.css">

<!-- after -->
<link rel="stylesheet" href="/static/css/xterm.css">

Alternatively, detect when public_url is the generic bind address (0.0.0.0 or ::) and fall back to Host header–based URL generation.

[henfri]

Is there any workaround?

[dhoomakethu]

Using absolute IP address works, thats the only work-around I could think of not so reliable though.

[pizzaisdavid]

I'm am not sure if this is the same exact thing, as I am using textual serve ./main.py in a Dockerfile and have similar issues.

I did find a workaround using a proxy inside of the Dockerfile.

Dockerfile

FROM python:3.9-slim

RUN \
  apt-get update && \
  apt-get install -y socat && \
  pip install textual textual-dev

WORKDIR /app

COPY main.py main.py

CMD ["sh", "-c", "textual serve main.py --host 127.0.0.1 --port 8000 & socat TCP-LISTEN:8001,fork TCP:127.0.0.1:8000"]

main.py

from textual.app import App
from textual.widgets import Button

class Test(App):
    def compose(self):
        yield Button("hello world")

if __name__ == "__main__":
    Test().run()

commands:

docker build -t instance .
docker run -it -p 8000:8001 instance

So essentially, textual runs on 127.0.0.1:8000 and with our browser we go to 127.0.01:8000, but in-between we map to 0.0.0.0:8001.

[pizzaisdavid]

My above solution works when you are running it on your own machine, but my solution won't work if the dockerfile is being ran on a remote server.

[pizzaisdavid]

Regarding the remote server, my solution was to use the public_url property.