- Employee laptops have normal internet access and VPN access.
- Den web and Den API run inside the customer’s private network.
- The desktop is configured with one customer Den URL over the VPN.
What the desktop must reach
Use one desktop-facing Den origin when you can: the Den web origin, with its/api/den route proxying to Den API inside your deployment. The signed-in desktop runtime is pointed at that Den web URL and derives API and MCP traffic from it:
- API:
<den-web-origin>/api/den/v1/... - MCP:
<den-web-origin>/api/den/mcp/...
DEN_API_PUBLIC_URL still must be configured correctly, but it does not need to be a second desktop-facing origin. In the single-origin shape, set it to the proxied API base, for example https://openwork.example.internal/api/den. Den uses that value for install-link claims, OAuth callbacks, webhooks, MCP resource/audience values, and links.
If you publish a separate Den API origin, the one-time install-link exchange and external MCP clients must be able to reach that origin too.
External MCP clients such as Cursor, Claude Code, VS Code, ChatGPT, and OpenCode are separate from the desktop. They must reach the MCP endpoint you configure for them, usually <DEN_API_PUBLIC_URL>/mcp/agent; with the single-origin proxy example above, that is https://openwork.example.internal/api/den/mcp/agent. See OpenWork Connect MCP for the external-client flow.
Unless you mirror or replace public dependencies internally, laptops may also need outbound access for installers, release assets, npm packages used by npx, and the OpenCode model catalog. Keep that allowlist in Outbound network access, and use Installer delivery when installer downloads must stay inside Den.
What Den must reach
The hard requirements are small:- The MySQL-compatible database endpoint configured for Den.
- The OpenWork chart and images at deploy or image-pull time, unless you mirror the Helm chart and enabled images into an internal registry.
Three surprises for operators
Internal MCP servers are refused
Symptom: adding or testing an MCP server on a private address fails withMCP_URL_BLOCKED and the operator action says: “Use a public HTTPS MCP URL or change the deployment’s private-network policy through security review.”
Why: Den fetches MCP URLs server-side. By default, it blocks private and reserved addresses as SSRF protection for multi-tenant deployments.
Fix: set DEN_ALLOW_PRIVATE_MCP_URLS=1 on Den, or the matching Helm public config value. This disables that SSRF protection, so use it only when Den’s network position is trusted and the people allowed to add MCP connections are trusted.
The Cloud MCP diagnostic is skipped
Symptom:Settings → Debug reports that the live cloud catalog was not observed, and the detail says the endpoint is outside the diagnostics trust policy.
Why: the diagnostic only sends a credentialed probe to trusted origins. By default, it trusts the hosted OpenWork origins, not your self-hosted Den origin.
Fix: trust your Den origin before OpenWork launches. This affects the diagnostic only; Cloud MCP itself can still work in real chats without this variable, so do not treat a skipped probe as proof that the deployment is broken. See Network diagnostics for exact syntax and launch-surface guidance.
Den’s outbound self-check points at a public host
Symptom: an admin-triggered Den outbound diagnostic cannot reach the default public diagnostic host from a VPN-isolated Den deployment. Why:DEN_DIAGNOSTICS_ORIGIN defaults to the public OpenWork diagnostic service.
Fix: deploy the diagnostics app at an internally reachable supported runtime/origin, then point Den at it with DEN_DIAGNOSTICS_ORIGIN and DEN_DIAGNOSTICS_BEARER_TOKEN. Do not assume a generic Kubernetes package unless your deployment path has been validated. The check is optional and admin-triggered; it is not a background dependency for Den. See Network diagnostics.