Access Externally

[prelegalwonder]

This might be two issues and if so, feel free to let me know and I can start a second discussion.

After bootstrapping dream-server I get a handful of url's on localhost and then the routable IP for the system.
If you try to access the dream-server from another host on the local network, none of the docker services are exposed externally.

I know how to do this manually but seeing as there are several services, I was wondering if this was already something baked into the platform and I just need to tweak a config to get it going?

If there's not something baked into the platform, a suggestion:
A master nginx reverse proxy that does all of the forwarding for each of the services based on URI and you only need one port open and the rest of the internal-communication happens over the docker network.

I'm happy to take a shot at contributing this if there's not already a solution in place. I just didn't want to re-invent the wheel if you guys had something already.

[JeBuSBrian]

I'm looking for the same thing. I'd like dreamserver's whole ecosystem available to local network. For example, one machine might be a software dev machine connecting for coding, another might just need a chat interface, etc. Is there a solution for that, yet?

[datagod]

I too would like this ability. I installed Dream Server on a headless server.

[Lightheartdevs]

Yes, agreed. This is exactly the use case we want Dream Server to support cleanly: install it on a headless/server box, then reach the useful surfaces from other machines on the LAN without hand-editing every Docker port.

The direction we’re actively shipping is dream-proxy: one LAN-facing reverse proxy, with traffic forwarded over the Docker network and friendly hostnames like chat.<device>.local, dashboard.<device>.local, etc. PR #1366 is a good example of that work taking shape: #1366

We’re being a little careful about the final defaults. The goal is not just “proxy every container that has a port,” because some services are user-facing UIs and some are raw/internal APIs. The shape we want is:

• user-facing LAN access by default for things like chat/dashboard;
• developer/API surfaces available by explicit opt-in;
• internal/raw services kept protected unless an operator intentionally exposes them;
• clear docs for LAN and Tailscale/WireGuard access.

So: yes, this is very much on the path, and the feedback here helps confirm that it should be treated as a first-class headless/LAN setup flow rather than a manual workaround.