Allow Docker container to accept env var for Server URL?

[cowboy]

Have you considered allowing people to specify an env var for the Server URL when deloying in a Docker container? That way, nextflux can be deployed alongside miniflux and the user can simply log in with a username + password or a token, without needing to re-enter the server URL (which would have already been specified).

Thanks!

[ideologysec]

+1, especially since when deployed as a docker compose with non-standard ports, I can't actually get Nextflux to connect.

localhost? ipv4 address? ports?

being able to link up via the docker network would be very helpful.

[PhiFever]

+1, Just in one docker compose I can manage anything

[AiraNadih]

@cowboy This is technically feasible — the common approach for SPAs is to have an entrypoint script generate a config.js with something like window.__CONFIG__ = { serverUrl: "..." } at container startup, so you don't need to rebuild the image. It's a well-known pattern and not particularly complex to implement.

That said, the Server URL only needs to be entered once at login and is then persisted in the browser. So the actual time saved is minimal for most self-hosted setups.

Also worth noting for others following this thread: regardless of how the URL is injected, it must be an address reachable by the user's browser (e.g. https://miniflux.example.com or http://localhost:8080). Docker-internal hostnames like http://miniflux:8080 will not work, because nextflux is a client-side SPA — all API requests are made from the browser, not from the container.

---

Just want to clarify something that might help both @ideologysec and @PhiFever:

nextflux is a purely client-side SPA. This means all API requests to Miniflux are made from your browser, not from the nextflux container. The Docker container only serves static files (HTML/JS/CSS) — it does not proxy requests to Miniflux.

This has an important implication: you cannot use Docker-internal hostnames (e.g. http://miniflux:8080) as the Server URL, even if both services are in the same docker-compose network. Your browser has no idea how to resolve Docker's internal DNS.

The solution is to put Miniflux behind a reverse proxy (Caddy, Nginx, Traefik, etc.) so that it's accessible via a URL your browser can reach. For example:

# docker-compose.yml (simplified)
services:
  miniflux:
    image: miniflux/miniflux:latest
    # ...
  nextflux:
    image: electh/nextflux:latest
    # ...
  caddy:
    image: caddy:latest
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile

# Caddyfile
miniflux.example.com {
    reverse_proxy miniflux:8080
}

nextflux.example.com {
    reverse_proxy nextflux:80
}

Then you'd use https://miniflux.example.com as your Server URL in nextflux. An env var for pre-filling the URL wouldn't solve the underlying connectivity issue here.

[dudumaroja]

I whould love to set the server and hide the option from the user.. so only my server can be used with my nextflux..

as it its other people can use your intance if you plan to expose it

[cowboy]

@cowboy This is technically feasible — the common approach for SPAs is to have an entrypoint script generate a config.js with something like window.__CONFIG__ = { serverUrl: "..." } at container startup, so you don't need to rebuild the image. It's a well-known pattern and not particularly complex to implement.

That said, the Server URL only needs to be entered once at login and is then persisted in the browser. So the actual time saved is minimal for most self-hosted setups.

Yeah, that's why I suggested it. The first thing I did before running the container was to look for an environment variable where I could specify a server URL that would get built into a JS file or served via API endpoint, but didn't see anything. It would be nice to have the option to specify that URL to simplify access for the few people who will be using this.

I completely understand that Nextflux is a client-side app that could technically be used to access any Miniflux instance, but for me it's not about locking it down, but instead about simplicy and ease of use.