feat(container): self-hostable container image with runtime configuration

[svalleru]

Summary

Run the Dashboard from one prebuilt container image with runtime configuration. The authenticated layout passes only the public domain and optional sandbox URL to the terminal and filesystem inspector through ClientConfigProvider. Validation is centralized in src/lib/env.ts and runs at server startup even with telemetry disabled. PUBLIC_E2B_DOMAIN is required; legacy configuration names are rejected with migration guidance. API and sandbox URL overrides remain optional, preserving domain-based routing. Request headers never select SDK destinations.

Validation

• 320 unit and integration tests pass, including missing-domain and removed-variable rejection, shared URL/cookie validation, provider delivery, and forged-header routing regressions. TypeScript, Biome for changed files, and the CI files/dependencies Knip check pass.
• Production Docker build and smoke checks pass for normal startup and invalid configuration. Browser verification against a mock API confirmed hydration, interactive controls, and the plain-HTTP cookie flag. A live sandbox session was not rerun for this update.

Deployment notes

Rename NEXT_PUBLIC_E2B_DOMAIN to PUBLIC_E2B_DOMAIN, the API overrides to E2B_INFRA_API_URL / E2B_DASHBOARD_API_URL, and either sandbox alias to PUBLIC_SANDBOX_URL. Remove the old keys even when the replacements are present. Restart the container and reload open pages after changes. A sandbox override must be reachable from both browser and server; DASHBOARD_COOKIE_SECURE=false supports plain HTTP, with secure cookies remaining the production default. The image runs as a non-root user on port 3001. Builds require outbound HTTPS for Google Fonts; the path-filtered Container check should not be required.

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Independence Check.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Independence Check.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Independence Check.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[claude]

I reviewed this PR and didn't find any new bugs. The commit pushed since my last review (8631ec1) substantively addresses the concerns raised in my earlier passes: the header-derived sandbox-origin fallback that trusted X-Forwarded-Host/Proto (the SSRF-adjacent path) was removed entirely in favor of operator-configured values only, resolveSandboxUrl() is now validated eagerly at startup via validateRuntimeConfig() alongside the other URL resolvers, and isSecureCookie() now throws on an unrecognized DASHBOARD_COOKIE_SECURE value instead of silently falling back to secure=true. Because this PR still touches auth-cookie handling, request-origin/URL resolution, and container startup validation, a human look is worthwhile as an additional step before merging.

Extended reasoning...

Overview

Since my previous reviews on this PR, one further commit (8631ec1, "fix(config): validate startup settings and use configured sandbox URLs") landed. I re-ran the full diff against the base and read the current state of src/core/server/runtime-config.ts, src/configs/cookies.ts, src/instrumentation.ts, and src/core/server/api/routers/sandbox.ts directly (not just relying on the resolution metadata) to confirm what changed.

Security risks

All four items I previously flagged across two reviews were substantively fixed in this commit, verified by direct code reading:

• The entire requestOrigin()/forwardedProtocol()/hostnameOf()/resolveServerSandboxUrl() machinery that trusted X-Forwarded-Host/X-Forwarded-Proto with no allow-list (the SSRF concern) was deleted. resolveBrowserRuntimeConfig() and the sandbox router now call the header-free resolveSandboxUrl(), which only reads operator-set env vars — this also moots the related multi-value X-Forwarded-Host parsing bug, since that code path no longer exists.
• resolveSandboxUrl() is now called eagerly from a new validateRuntimeConfig(), invoked from src/instrumentation.ts's register() at server startup (with process.exit(1) on failure), closing the gap where a malformed sandbox URL previously surfaced only when a user opened a terminal.
• isSecureCookie() now explicitly matches 'true'/'false' and throws on anything else, rather than treating any non-'false' string (e.g. '0', 'off') as secure=true; this throw is also wired into validateRuntimeConfig() so a bad DASHBOARD_COOKIE_SECURE fails startup instead of silently reproducing the plain-HTTP login loop the variable exists to fix.
• New tests in tests/integration/runtime-config-startup.test.ts cover startup rejection for each malformed URL var and for an invalid cookie flag, plus successful startup with a valid configuration — matching the code changes.

I did not find new security issues in this delta; the change is a genuine narrowing of trust (removing a header-trust path) plus fail-fast validation, not new attack surface.

Level of scrutiny

This PR remains large and touches security-relevant code (auth cookie flags, server-side URL/origin resolution used for SDK routing, container startup). That, combined with the significant design change in this latest commit (removing the request-header-based sandbox routing entirely), is exactly the kind of change where a maintainer's sign-off adds value beyond an automated pass, even though the automated review this round found nothing new and confirms the previously raised issues were fixed correctly.

Other factors

The fix commit was authored by drankou, who is a CODEOWNER for this repository (per CODEOWNERS), and the same person resolved the four inline threads I had opened — this is independent-of-author engagement, and my own reading of the code corroborates that the resolutions reflect real fixes rather than administrative closures. No CHANGES_REQUESTED or unresolved third-party objections remain visible in the timeline. Test coverage for the new startup-validation and cookie paths is present and appears to match the implementation.

This review covers commit 8631ec1, which is no longer the latest commit on this pull request; later commits are not covered by it.

[linear-code]

EN-2779