fix: dynamically report backend_host in terminal logs #6165

[pranavmanglik]

All Submissions:

• Have you followed the guidelines stated in [CONTRIBUTING.md](https://github.com/reflex-dev/reflex/blob/main/CONTRIBUTING.md) file?
• Have you checked to ensure there aren't any other open [Pull Requests](https://github.com/reflex-dev/reflex/pulls) for the desired changed?

Type of change

• Bug fix (non-breaking change which fixes an issue)

New Feature Submission:

• Does your submission pass the tests?
• Have you linted your code locally prior to submission?

Changes To Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you successfully ran tests with your changes locally?

Pull Request Details

Descriptive Title

fix: accurately report configured backend_host in terminal logs

Description of Changes

Currently, the notify_backend function in reflex/utils/exec.py has the backend IP hardcoded as 0.0.0.0. This leads to misleading terminal output when a user has explicitly configured a custom backend_host (e.g., 127.0.0.1 for local-only development) in their rxconfig.py.

This PR modifies the notification logic to dynamically pull the backend_host from the Reflex configuration, ensuring the logs match the actual network binding. This improves developer clarity and assists in verifying security configurations.

Testing performed:

• Verified on EndeavourOS by setting backend_host="127.0.0.1" in rxconfig.py.
• Confirmed terminal output correctly displays http://127.0.0.1:8000 instead of the hardcoded 0.0.0.0.
• Ensured local linting (ruff) passes.

Closing Issues

Closes #6165

[greptile-apps]

Greptile Summary

This PR fixes a bug in notify_backend() where the terminal log message for the backend URL was always hardcoded to http://0.0.0.0:<port> regardless of the user's backend_host configuration. The change dynamically reads the host from the Reflex config object, which correctly reflects values set in rxconfig.py.

Changes made:

• In reflex/utils/exec.py, notify_backend() now calls get_config() once and uses config.backend_host instead of the hardcoded 0.0.0.0 string.

Issue found:

• The fix only covers the case where backend_host is configured in rxconfig.py. If the user overrides the host via the CLI (reflex run --backend-host <value>), the resolved host is computed as backend_host = backend_host or config.backend_host in _run() but is never persisted back to the config object (unlike backend_port, which uses config._set_persistent). This means notify_backend() will still read a stale config.backend_host and log an incorrect URL in the CLI-override scenario. The function signature should accept the resolved host argument from run_backend/run_backend_prod to handle this correctly.

Confidence Score: 3/5

• Safe to merge for the rxconfig.py use case, but the fix is incomplete for CLI --backend-host overrides.
• The change is a small, isolated improvement that fixes the reported issue for the primary use case (rxconfig.py). However, the --backend-host CLI scenario is not covered because the resolved host is not propagated to notify_backend(), leaving the same misleading log output for that code path. No tests appear to cover the notification output, so the gap could persist unnoticed.
• reflex/utils/exec.py — the notify_backend function and its two call-sites in run_backend / run_backend_prod.

Important Files Changed

Filename	Overview
reflex/utils/exec.py	Replaces hardcoded 0.0.0.0 with config.backend_host in notify_backend(). Correctly fixes the rxconfig.py case, but misses CLI --backend-host overrides because the resolved host is never persisted back to the config object.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["reflex run [--backend-host HOST]"] --> B["_run() in reflex.py"]
    B --> C["backend_host = cli_arg OR config.backend_host"]
    C --> D{"frontend present?"}
    D -- No --> E["run_backend(host, port, ...)"]
    D -- Yes --> F["run_frontend + run_backend (concurrent)"]
    E --> G{"not frontend_present?"}
    G -- Yes --> H["notify_backend()"]
    H --> I["config = get_config()"]
    I --> J["reads config.backend_host ← may differ from resolved 'host'"]
    J --> K["Logs: Backend running at http://config.backend_host:port"]
    E --> L["Binds server to resolved 'host'"]
    K -.->|"Mismatch when --backend-host CLI arg used"| L

Loading

Comments Outside Diff (1)

1. reflex/utils/exec.py, line 162-165 (link)

   CLI --backend-host override not reflected

   notify_backend() reads the host from config.backend_host, but this config value is not updated when the user supplies a --backend-host CLI argument. The actual host used for binding (available as the host parameter in both run_backend and run_backend_prod) is resolved via backend_host = backend_host or config.backend_host in _run(), but is never persisted back into the config object — unlike backend_port, which is stored with config._set_persistent(backend_port=...).

   As a result, running reflex run --backend-host 192.168.1.1 will bind the server to 192.168.1.1 but will still log http://0.0.0.0:8000 (or whatever rxconfig.py contains).

   The fix correctly covers the rxconfig.py case, but misses the CLI-override case. The cleanest solution is to accept the actual resolved host as a parameter:

   def notify_backend(host: str | None = None):
       """Output a string notifying where the backend is running."""
       config = get_config()
       effective_host = host or config.backend_host
       console.print(
           f"Backend running at: [bold green]http://{effective_host}:{config.backend_port}[/bold green]"
       )

   And update the call-sites in run_backend / run_backend_prod:

   if not frontend_present:
       notify_backend(host)

_{Last reviewed commit: eb595af}

[codspeed-hq]

Merging this PR will not alter performance

✅ 8 untouched benchmarks

---

_{Comparing pranavmanglik:fix-backend-host-hardcoding-in-logs (7dc4082) with main (fe34ae8)}

[masenf]

instead of calling get_config() twice, cache the returned config and reference it in both places.

[pranavmanglik]

Thanks for your response, i actually new to open source. I thought about it but then had doubt if it was that necessary as it was being called twice only.

[pranavmanglik]

Yeah, that looks fine.