fix(docker): bind all interfaces so the in-app scheduler loopback works#541
Conversation
Next standalone binds to $HOSTNAME, which Kubernetes sets to the pod name — the server then only listens on the pod IP and the scheduler's loopback POSTs to 127.0.0.1:3000 fail with ECONNREFUSED. ENV HOSTNAME=0.0.0.0 makes the image bind all interfaces regardless of the deployment's env.
![its-saffron[bot]](https://avatars.githubusercontent.com/in/3901073?s=60&v=4){kind=small}
There was a problem hiding this comment.
AI Automated Review
Full PR review.
Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_low_confidence)
Recommendation: Approve
This is a focused, well-reasoned fix that correctly addresses the in-app scheduler loopback connectivity issue in Kubernetes deployments.
Change Summary
File: Dockerfile (lines 57-60, new)
Adds ENV HOSTNAME=0.0.0.0 to the runner stage. Next.js standalone mode binds to $HOSTNAME; without this fix, Kubernetes sets HOSTNAME to the pod name (which resolves to the pod IP), causing the server to skip loopback and break the scheduler's 127.0.0.1:3000 POSTs.
Standards Compliance
- Docker conventions: Follows existing ENV pattern in the runner stage (adjacent to
ENV PORT=3000on line 55) - Multi-stage build: No change to build structure
- Binary targets: No schema changes; Prisma not affected
- No secrets committed: No sensitive values added
Technical Correctness
- The
src/lib/scheduler.tsshows the scheduler useshttp://127.0.0.1:${port}for loopback POSTs - The fix ensures the Next.js standalone server binds
0.0.0.0:3000, making loopback connections work in-cluster - The referenced Helm workaround (joryirving/home-ops PR 7975) is now baked into the image, simplifying deployment
CI Check Results
| Check | Status |
|---|---|
| Tests | ✓ success |
| Build | ✓ success |
| Lint | ✓ success |
| Typecheck | ✓ success |
| Docker Build | ✓ success |
Linked Issue Fit
No linked issues; PR body provides clear justification and in-cluster verification evidence.
Findings
None. The change is minimal (5 lines: 1 blank + 1 comment + 1 comment + 1 blank + 1 ENV), surgical, and all checks pass.
1 participant
Summary
ENV HOSTNAME=0.0.0.0in the runner stage.Next standalone binds to
$HOSTNAME; Kubernetes sets it to the pod name, so the server only listened on the pod IP and the in-app scheduler's loopback POSTs to127.0.0.1:3000all failed with ECONNREFUSED (probes pass — they hit the pod IP). Baking the bind address into the image removes the need for theHOSTNAME: 0.0.0.0env workaround in the HelmRelease (joryirving/home-ops#7975).Verification
HOSTNAME=0.0.0.0the boot log showsNetwork: http://0.0.0.0:3000and scheduler jobs reach the server.