d3k hardcodes localhost when constructing the browser URL (http://localhost:{port}). This makes it incompatible with tools like vercel-labs/portless that route via hostname (e.g. http://myapp.localhost:1355).
Running d3k --command "portless myapp next dev" partially works. d3k picks up the random port from Next.js stdout and connects directly, bypassing the portless proxy. But this loses the named URL benefits (stable cookies, no port conflicts, readable URLs).
Activity
4
JiwaniZakir7mo agoThe root cause is almost in the URL construction step after port detection — d3k correctly parses the port emitted to stdout (e.g., from Next.js's ready on line), but then assembles the browser URL by hardcoding hostname = "localhost" rather than making it configurable. With portless in the mix, the meaningful address is myapp.localhost:1355 (the proxy entry point), but d3k discards that and dials the underlying raw port directly, which bypasses the proxy entirely. Look for wherever the final http://localhost:{port} string is built — likely a getDevUrl or openBrowser utility — that's where a --hostname flag or D3K_HOSTNAME env var would need to feed in.
elsigh7mo agoIf you want to vibe code and send a PR that would be welcome - there are some guts in the codebase to support portless but I haven't been testing/hacking with it
angusfretwell7mo ago@elsigh for my use case, being able to pass in an option to set preferredAppUrl (like d3k --app-url ...) would solve this. Can send a PR if that sounds alright?
I'm shipping with a portless integration today but it'll be behind a flag due to https://github.com/vercel-labs/portless/issues/58