Improve dev host handling and clarify backend port configuration#532
Improve dev host handling and clarify backend port configuration#532blackmammoth wants to merge 11 commits intomainfrom
Conversation
Running `vite --host` exposes the dev server on all interfaces. However, we should expose it on all interfaces only when `HOST` is set to `0.0.0.0`. Otherwise, we should assume the user wants to bind to a host of their choice and not expose the server on the network.
Previously, the server redirected to Vite using `localhost` as the hostname. Even if the user was using HOST="0.0.0.0", if they connected to server from another device on the same network using `http://<host_ip>:3001`, the server would redirect them to `http://localhost:5173`, which would not work since `localhost` would resolve to the client's machine instead of the server.
- Normalize all localhost variants to 'localhost' for consistent proxy configuration in Vite and server setup. - use one source of truth for network hosts functions by moving them to a shared - log production and development urls
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughRename backend port env var from PORT to SERVER_PORT across configs, docs, CLI, server code, and Vite; add shared host utilities for loopback/wildcard normalization; update server startup to compute display hosts, start plugin servers, and initialize a projects watcher. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI
participant Server
participant Watcher
participant Plugins
participant Vite
participant Browser
CLI->>Server: start (reads SERVER_PORT, HOST, fallbacks)
Server->>Watcher: setupProjectsWatcher()
Server->>Plugins: startEnabledPluginServers()
Server->>Vite: configure dev proxy targets using getConnectableHost(HOST) and SERVER_PORT
Browser->>Vite: request assets / WS
Browser->>Server: HTTP request (may be redirected to connectable host:SERVER_PORT)
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
server/cli.js (1)
133-137:⚠️ Potential issue | 🟡 Minor
cloudcli statuscan still print a non-working URL.This stays pinned to
localhost, soHOST=192.168.x.xor a custom hostname makes the hint incorrect even though the server is listening elsewhere. Reuse the same host normalization helper here so the CLI output matches the actual bind address.As per coding guidelines,
npm run dev starts both frontend and backend; ensure HOST/port handling aligns with new SERVER_PORT logic.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/cli.js` around lines 133 - 137, The printed UI hint in server/cli.js currently hardcodes "localhost" and uses process.env.SERVER_PORT || '3001', which can show an incorrect URL for non-local binds; change the cloudcli status output to build the host/port using the same host normalization helper used elsewhere (e.g., normalizeHost or getServerUrl) so it uses process.env.HOST (or the normalized host) and process.env.SERVER_PORT consistently; update the console.log line that prints "Access the UI at http://localhost:${process.env.SERVER_PORT || '3001'}" to call the shared helper (or compose host = normalizeHost(process.env.HOST) and port = process.env.SERVER_PORT || '3001') so the hint matches actual bind address.server/routes/taskmaster.js (1)
530-536:⚠️ Potential issue | 🟠 MajorDon't keep the fallback pinned to
localhost.When
HOSTis set to a specific LAN IP/hostname, this self-call can miss the interface the server actually bound to, so the TaskMaster fallback stops working in the remote-access setups this PR is targeting. Reuse the shared host helper here, or better, avoid the HTTP hop and call the task-loading logic directly.As per coding guidelines,
npm run dev starts both frontend and backend; ensure HOST/port handling aligns with new SERVER_PORT logic.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/routes/taskmaster.js` around lines 530 - 536, The fallback should not hardcode localhost: replace the HTTP self-call (the fetch using process.env.SERVER_PORT and projectName) by either (A) using the shared host helper (e.g., getServerHost/getHost) to build the URL instead of `localhost`, or preferably (B) avoid the HTTP hop entirely by calling the internal task-loading function directly (e.g., TaskMaster.loadTasks / loadProjectTasks or the module that returns tasks for projectName) and passing along authorization/context from req (req.headers.authorization) so auth checks still run; also ensure this change respects the SERVER_PORT/HOST handling used by npm run dev.
🧹 Nitpick comments (1)
server/index.js (1)
34-34: Remove the temporary env debug print.This runs on every startup and duplicates the structured readiness logging below. It looks like leftover debugging noise.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/index.js` at line 34, Remove the temporary environment debug print by deleting the console.log('SERVER_PORT from env:', process.env.SERVER_PORT); statement in server/index.js so startup doesn't emit duplicate, noisy logs; rely on the existing structured readiness logging instead.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.ko.md`:
- Line 73: Update the README sentence to mention both configured HOST and
SERVER_PORT instead of hardcoding "localhost": change the line that currently
references `http://localhost:3001` to construct the URL using the `HOST` and
`SERVER_PORT` environment variables (e.g., mention "http://<HOST>:<SERVER_PORT>
or http://localhost:<SERVER_PORT> if HOST is unset"), and also add a short note
that `npm run dev` starts both frontend and backend and will respect the HOST/
SERVER_PORT environment variables so host/port handling matches the new
networking behavior.
In `@shared/networkHosts.js`:
- Around line 16-22: getConnectableHost currently returns raw host strings (used
by callers to build http:// and ws:// authorities) which breaks for IPv6
literals like "2001:db8::10"; add a small helper (e.g. formatHostForURL or
bracketIPv6Host) that detects IPv6 literals and wraps them in square brackets
per RFC (and otherwise returns the host unchanged), update all call sites that
interpolate hosts into URLs (startup redirects, proxy targets, dev server URLs)
to call this helper instead of using getConnectableHost directly, and keep
getConnectableHost's behavior for wildcard/loopback detection (isWildcardHost,
isLoopbackHost) unchanged; also verify the host+port assembly at those call
sites uses the new SERVER_PORT handling so HOST and port logic remain consistent
with npm run dev semantics.
---
Outside diff comments:
In `@server/cli.js`:
- Around line 133-137: The printed UI hint in server/cli.js currently hardcodes
"localhost" and uses process.env.SERVER_PORT || '3001', which can show an
incorrect URL for non-local binds; change the cloudcli status output to build
the host/port using the same host normalization helper used elsewhere (e.g.,
normalizeHost or getServerUrl) so it uses process.env.HOST (or the normalized
host) and process.env.SERVER_PORT consistently; update the console.log line that
prints "Access the UI at http://localhost:${process.env.SERVER_PORT || '3001'}"
to call the shared helper (or compose host = normalizeHost(process.env.HOST) and
port = process.env.SERVER_PORT || '3001') so the hint matches actual bind
address.
In `@server/routes/taskmaster.js`:
- Around line 530-536: The fallback should not hardcode localhost: replace the
HTTP self-call (the fetch using process.env.SERVER_PORT and projectName) by
either (A) using the shared host helper (e.g., getServerHost/getHost) to build
the URL instead of `localhost`, or preferably (B) avoid the HTTP hop entirely by
calling the internal task-loading function directly (e.g., TaskMaster.loadTasks
/ loadProjectTasks or the module that returns tasks for projectName) and passing
along authorization/context from req (req.headers.authorization) so auth checks
still run; also ensure this change respects the SERVER_PORT/HOST handling used
by npm run dev.
---
Nitpick comments:
In `@server/index.js`:
- Line 34: Remove the temporary environment debug print by deleting the
console.log('SERVER_PORT from env:', process.env.SERVER_PORT); statement in
server/index.js so startup doesn't emit duplicate, noisy logs; rely on the
existing structured readiness logging instead.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 95d78591-0d28-4f0c-8172-e4c1f828823f
📒 Files selected for processing (10)
.env.exampleREADME.ja.mdREADME.ko.mdREADME.zh-CN.mdpackage.jsonserver/cli.jsserver/index.jsserver/routes/taskmaster.jsshared/networkHosts.jsvite.config.js
| ``` | ||
|
|
||
| 서버가 시작되면 `http://localhost:3001` (또는 설정한 PORT)에서 접근할 수 있습니다. | ||
| 서버가 시작되면 `http://localhost:3001` (또는 설정한 SERVER_PORT)에서 접근할 수 있습니다. |
There was a problem hiding this comment.
Document the host as well as the port.
This sentence still hardcodes localhost, so it becomes inaccurate when HOST is set to a specific LAN IP or hostname. Mention the configured host alongside SERVER_PORT here to match the new networking behavior.
As per coding guidelines, npm run dev starts both frontend and backend; ensure HOST/port handling aligns with new SERVER_PORT logic.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.ko.md` at line 73, Update the README sentence to mention both
configured HOST and SERVER_PORT instead of hardcoding "localhost": change the
line that currently references `http://localhost:3001` to construct the URL
using the `HOST` and `SERVER_PORT` environment variables (e.g., mention
"http://<HOST>:<SERVER_PORT> or http://localhost:<SERVER_PORT> if HOST is
unset"), and also add a short note that `npm run dev` starts both frontend and
backend and will respect the HOST/ SERVER_PORT environment variables so
host/port handling matches the new networking behavior.
| // Use localhost for connectable loopback and wildcard addresses in browser-facing URLs. | ||
| export function getConnectableHost(host) { | ||
| if (!host) { | ||
| return 'localhost'; | ||
| } | ||
| return isWildcardHost(host) || isLoopbackHost(host) ? 'localhost' : host; | ||
| } |
There was a problem hiding this comment.
Bracket IPv6 literals before using these hosts in URLs.
getConnectableHost() returns raw host values, but the callers interpolate them into http:///ws:// URLs. A custom IPv6 host like 2001:db8::10 will produce an invalid authority (http://2001:db8::10:3001), so redirects, startup URLs, and proxy targets still break on IPv6 setups. Add a dedicated URL-formatting helper and use that wherever these hosts are rendered into URLs.
As per coding guidelines, npm run dev starts both frontend and backend; ensure HOST/port handling aligns with new SERVER_PORT logic.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@shared/networkHosts.js` around lines 16 - 22, getConnectableHost currently
returns raw host strings (used by callers to build http:// and ws://
authorities) which breaks for IPv6 literals like "2001:db8::10"; add a small
helper (e.g. formatHostForURL or bracketIPv6Host) that detects IPv6 literals and
wraps them in square brackets per RFC (and otherwise returns the host
unchanged), update all call sites that interpolate hosts into URLs (startup
redirects, proxy targets, dev server URLs) to call this helper instead of using
getConnectableHost directly, and keep getConnectableHost's behavior for
wildcard/loopback detection (isWildcardHost, isLoopbackHost) unchanged; also
verify the host+port assembly at those call sites uses the new SERVER_PORT
handling so HOST and port logic remain consistent with npm run dev semantics.
|
@blackmammoth as this is a breaking change, would it make sense to have still have the port link to the server_port as a fallback? |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.env.example:
- Line 20: Add back a deprecated PORT entry to the .env.example and a short
migration note, and ensure runtime uses PORT as a fallback by checking
process.env.SERVER_PORT || process.env.PORT || 3001; specifically, restore a
line for PORT with a comment about deprecation next to SERVER_PORT and update
any places that read process.env.SERVER_PORT to fall back to process.env.PORT
(i.e., change usages that currently do process.env.SERVER_PORT || 3001 to
process.env.SERVER_PORT || process.env.PORT || 3001).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 1b4e4b0e-76ab-451c-a537-5cd1a6875c13
📒 Files selected for processing (2)
.env.examplepackage.json
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
Every default values have not been changed so it shouldn't have broken any existing functionality. Can you share snippets of the codebase that are breaking changes? |
It's not about the default but existing installations where the users might have changed the .env PORT value to something else than the default one |
understood. I have added a commit for this. I have also added a TODO comment for removing the PORT variable from a future major release. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@server/cli.js`:
- Around line 289-290: The CLI currently only writes the CLI flag into
process.env.SERVER_PORT (via options.serverPort), which prevents legacy PORT env
vars from reaching code that still reads PORT; update the logic so that when
options.serverPort is provided you set both process.env.SERVER_PORT and
process.env.PORT to that value, and when options.serverPort is not provided but
process.env.PORT exists you propagate process.env.PORT into
process.env.SERVER_PORT (i.e., set SERVER_PORT = PORT) so both old and new
consumers (e.g., server boot logic and vite proxy) see the same port value.
- Line 137: The status output currently hardcodes "localhost" in the
console.log; replace that with the same connectable-host logic used elsewhere so
the printed UI URL matches actual access behavior. Import or require the
existing helper (e.g., connectableHost or getConnectableHost), compute the host
to use (falling back to the same env vars used to start the server), and
substitute that host into the template string in the console.log call instead of
the literal 'localhost'. Ensure the port resolution remains identical to the
existing expression (process.env.SERVER_PORT || process.env.PORT || '3001') so
only the host selection changes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 243e1340-5285-4edf-a43e-966ea7436f32
📒 Files selected for processing (3)
server/cli.jsserver/routes/taskmaster.jsvite.config.js
🚧 Files skipped from review as they are similar to previous changes (1)
- server/routes/taskmaster.js
| console.log(` ${c.dim('>')} Use ${c.bright('cloudcli --database-path /path/to/db')} for custom database`); | ||
| console.log(` ${c.dim('>')} Run ${c.bright('cloudcli help')} for all options`); | ||
| console.log(` ${c.dim('>')} Access the UI at http://localhost:${process.env.PORT || '3001'}\n`); | ||
| console.log(` ${c.dim('>')} Access the UI at http://localhost:${process.env.SERVER_PORT || process.env.PORT || '3001'}\n`); |
There was a problem hiding this comment.
Status output still hardcodes localhost.
With HOST=0.0.0.0 or a LAN address, this prints the wrong URL even though the rest of the PR now normalizes browser-facing hosts. Reuse the same connectable-host logic here so the status command matches actual access behavior.
Proposed fix
+import { getConnectableHost } from '../shared/networkHosts.js';+ const displayHost = getConnectableHost(process.env.HOST || '0.0.0.0');
- console.log(` ${c.dim('>')} Access the UI at http://localhost:${process.env.SERVER_PORT || process.env.PORT || '3001'}\n`);
+ console.log(` ${c.dim('>')} Access the UI at http://${displayHost}:${process.env.SERVER_PORT || process.env.PORT || '3001'}\n`);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| console.log(` ${c.dim('>')} Access the UI at http://localhost:${process.env.SERVER_PORT || process.env.PORT || '3001'}\n`); | |
| import { getConnectableHost } from '../shared/networkHosts.js'; | |
| const displayHost = getConnectableHost(process.env.HOST || '0.0.0.0'); | |
| console.log(` ${c.dim('>')} Access the UI at http://${displayHost}:${process.env.SERVER_PORT || process.env.PORT || '3001'}\n`); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@server/cli.js` at line 137, The status output currently hardcodes "localhost"
in the console.log; replace that with the same connectable-host logic used
elsewhere so the printed UI URL matches actual access behavior. Import or
require the existing helper (e.g., connectableHost or getConnectableHost),
compute the host to use (falling back to the same env vars used to start the
server), and substitute that host into the template string in the console.log
call instead of the literal 'localhost'. Ensure the port resolution remains
identical to the existing expression (process.env.SERVER_PORT ||
process.env.PORT || '3001') so only the host selection changes.
| if (options.serverPort) { | ||
| process.env.SERVER_PORT = options.serverPort; |
There was a problem hiding this comment.
Legacy PORT configs still won't reach the server.
This only forwards the CLI flag into SERVER_PORT. If an existing install sets PORT=4000 in the environment, server/index.js:2494-2519 still binds 3001 because it now reads only SERVER_PORT, while vite.config.js:18 still proxies to PORT. That breaks the legacy custom-port path this PR is trying to preserve.
Proposed fix
async function main() {
const args = process.argv.slice(2);
const { command, options } = parseArgs(args);
+ loadEnvFile();
// Apply CLI options to environment variables
if (options.serverPort) {
process.env.SERVER_PORT = options.serverPort;
+ } else if (!process.env.SERVER_PORT && process.env.PORT) {
+ process.env.SERVER_PORT = process.env.PORT;
}
if (options.databasePath) {
process.env.DATABASE_PATH = options.databasePath;
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@server/cli.js` around lines 289 - 290, The CLI currently only writes the CLI
flag into process.env.SERVER_PORT (via options.serverPort), which prevents
legacy PORT env vars from reaching code that still reads PORT; update the logic
so that when options.serverPort is provided you set both process.env.SERVER_PORT
and process.env.PORT to that value, and when options.serverPort is not provided
but process.env.PORT exists you propagate process.env.PORT into
process.env.SERVER_PORT (i.e., set SERVER_PORT = PORT) so both old and new
consumers (e.g., server boot logic and vite proxy) see the same port value.
There was a problem hiding this comment.
♻️ Duplicate comments (1)
server/cli.js (1)
289-293:⚠️ Potential issue | 🟠 MajorMissing
loadEnvFile()call before the PORT fallback logic.The fallback from
PORTtoSERVER_PORTwas added, but.envfile values still won't be picked up for thestartcommand. TheloadEnvFile()function is only called viagetDatabasePath()inshowStatus(), not beforestartServer().Scenario: User has
PORT=4000in.env, no CLI flag, no shellSERVER_PORT:
main()runs,process.env.PORTis still undefined (.envnot loaded)- Fallback on line 291-292 doesn't trigger
startServer()importsserver/index.js, which evaluatesSERVER_PORTas3001Proposed fix
async function main() { const args = process.argv.slice(2); const { command, options } = parseArgs(args); + + // Load .env before applying CLI options so PORT fallback works + loadEnvFile(); // Apply CLI options to environment variables if (options.serverPort) { process.env.SERVER_PORT = options.serverPort; } else if (!process.env.SERVER_PORT && process.env.PORT) { process.env.SERVER_PORT = process.env.PORT; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/cli.js` around lines 289 - 293, Call loadEnvFile() before evaluating the PORT→SERVER_PORT fallback in main() so .env values are available for startServer(); specifically, ensure loadEnvFile() is invoked (if not already) prior to the block that checks options.serverPort and process.env.PORT (the fallback logic around SERVER_PORT), so startServer() / server/index.js sees the .env-provided PORT; avoid duplicating loads already done in getDatabasePath()/showStatus().
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@server/cli.js`:
- Around line 289-293: Call loadEnvFile() before evaluating the PORT→SERVER_PORT
fallback in main() so .env values are available for startServer(); specifically,
ensure loadEnvFile() is invoked (if not already) prior to the block that checks
options.serverPort and process.env.PORT (the fallback logic around SERVER_PORT),
so startServer() / server/index.js sees the .env-provided PORT; avoid
duplicating loads already done in getDatabasePath()/showStatus().
|
@viper151 updated |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
server/index.js (1)
34-34: Remove debug log before merge.This appears to be leftover debugging code. Consider removing it to keep production logs clean.
🧹 Proposed fix
-console.log('SERVER_PORT from env:', process.env.SERVER_PORT);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@server/index.js` at line 34, Remove the leftover debug console.log in server/index.js that prints process.env.SERVER_PORT; locate the console.log('SERVER_PORT from env:', process.env.SERVER_PORT) statement and delete it (or replace with a proper logger call at an appropriate log level if intentional), ensuring no stray debug prints remain before merging.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@server/index.js`:
- Line 2496: Replace the current single-variable fallback for SERVER_PORT with
the same backward-compatible pattern used elsewhere: update the const
declaration for SERVER_PORT to check process.env.SERVER_PORT, then
process.env.PORT, then the numeric fallback (3001); i.e., change the initializer
for the SERVER_PORT variable so it uses process.env.SERVER_PORT ||
process.env.PORT || 3001 to restore compatibility with deployments that only set
PORT.
---
Nitpick comments:
In `@server/index.js`:
- Line 34: Remove the leftover debug console.log in server/index.js that prints
process.env.SERVER_PORT; locate the console.log('SERVER_PORT from env:',
process.env.SERVER_PORT) statement and delete it (or replace with a proper
logger call at an appropriate log level if intentional), ensuring no stray debug
prints remain before merging.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: f5be6ff6-6f84-4d07-beeb-f697a3ecaa4c
📒 Files selected for processing (5)
README.ja.mdREADME.ko.mdREADME.zh-CN.mdpackage.jsonserver/index.js
🚧 Files skipped from review as they are similar to previous changes (2)
- README.zh-CN.md
- README.ja.md
| } | ||
|
|
||
| const PORT = process.env.PORT || 3001; | ||
| const SERVER_PORT = process.env.SERVER_PORT || 3001; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check how SERVER_PORT and PORT are used across the codebase
echo "=== Files using SERVER_PORT ==="
rg -n 'SERVER_PORT' --type js
echo ""
echo "=== Files using PORT fallback pattern ==="
rg -n 'SERVER_PORT.*PORT|PORT.*SERVER_PORT' --type jsRepository: siteboon/claudecodeui
Length of output: 2819
Inconsistent PORT fallback—server/index.js is missing backward compatibility.
The codebase consistently implements a SERVER_PORT || PORT || fallback pattern for backward compatibility across vite.config.js, server/cli.js, and server/routes/taskmaster.js, but server/index.js:2496 omits the PORT fallback, breaking backward compatibility for deployments using only the PORT environment variable.
🔧 Proposed fix
-const SERVER_PORT = process.env.SERVER_PORT || 3001;
+// TODO: Remove support for legacy PORT variable in a future major release, leaving only SERVER_PORT.
+const SERVER_PORT = process.env.SERVER_PORT || process.env.PORT || 3001;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@server/index.js` at line 2496, Replace the current single-variable fallback
for SERVER_PORT with the same backward-compatible pattern used elsewhere: update
the const declaration for SERVER_PORT to check process.env.SERVER_PORT, then
process.env.PORT, then the numeric fallback (3001); i.e., change the initializer
for the SERVER_PORT variable so it uses process.env.SERVER_PORT ||
process.env.PORT || 3001 to restore compatibility with deployments that only set
PORT.
3 participants
https://cloudcli.ai/docs/network-architecture-guide-how-the-front-and-backend-interact
Why
Before these changes:
npm run clientalways started Vite with--host, which exposed the dev server on all interfaces even when that was not intended.http://localhost:<vite-port>, which breaks if a user opens the app from another device on the network.PORTwas ambiguous in a project that already usesVITE_PORT, and some internal server code still depended on that older name.What Changed
Development host handling
package.json--hostflag from the Vite client script so Vite respects the configuredHOSTinstead of always exposing the dev server.server/index.jslocalhost.vite.config.jslocalhost,127.0.0.1,::1, and[::1]into a consistent browser-facing host.shared/networkHosts.jsPort configuration cleanup
server/index.jsPORTtoSERVER_PORT.server/cli.jsSERVER_PORT.--port/-pas the CLI flagserver/routes/taskmaster.jsSERVER_PORTso server-to-server calls stay aligned with the new configuration name.Test Plan
HOST=0.0.0.0and open the app from another device on the same network; confirm the redirect points to a reachable host instead oflocalhost.SERVER_PORTand verify:SERVER_PORTlocalhost,127.0.0.1, and IPv6 loopback values.Summary by CodeRabbit
Chores
Refactor
New Features