Network, packages & managed devices
The checklist for the IT owner who manages proxies, egress, and endpoints. Everything here is knowable before day 0 — clear it alongside the procurement package and kickoff isn’t blocked on a firewall ticket.
Package management
Section titled “Package management”| Setup | What to do | How |
|---|---|---|
| Direct npm access | Nothing — registry.npmjs.org serves the public packages; your customer token unlocks the private ones | Self-service |
| Artifactory / Nexus proxy | Mirror the public packages through your proxy as usual; the private scoped packages need the customer token configured against the upstream registry in your proxy’s remote-repo config | Self-service, with your onboarding engineer on the call if wanted |
| No registry access at all | Offline installation is scoped with us on the Enterprise track — plan for extra lead time | Set up with us |
The customer npm token is scoped and read-only, expires with your term, and is the only Data Workers credential involved in installation.
Network egress
Section titled “Network egress”What engineer machines need outbound, by setup:
- Local installs (default): outbound HTTPS to your own data systems (Snowflake, BigQuery, your catalog — connections you already allow) and to your model provider. No Data Workers endpoint is required for local operation, because telemetry is off and nothing transits us.
- Pilot telemetry (per your agreement): outbound HTTPS to the Data Workers telemetry endpoint — usage counters only. Your onboarding engineer provides the exact hostname set for your allowlist during provisioning.
- Hosted endpoint users (
mcp.dataworkers.io): outbound HTTPS to that hostname. - Inbound: nothing. No listening ports, no webhooks required.
Private connectivity
Section titled “Private connectivity”For orgs that don’t allow public egress to vendor endpoints: AWS PrivateLink / GCP Private Service Connect, dedicated VPC, bring-your-own-cloud, and fully air-gapped deployment (including local model inference, so zero external calls) are all set up with us — scoped on the Enterprise deployment track.
TLS-intercepting proxies (Zscaler and friends)
Section titled “TLS-intercepting proxies (Zscaler and friends)”Zero-trust proxies that re-sign TLS are the most common cause of npx and endpoint
failures on managed fleets. The fix is standard: distribute your corporate root CA and
point Node at it (NODE_EXTRA_CA_CERTS=<path-to-corporate-ca.pem>, set fleet-wide via
MDM) and configure npm’s cafile the same way. Run the doctor on a proxied machine
before rollout — it fails fast and names the TLS problem if the CA isn’t trusted.
Windows and WSL
Section titled “Windows and WSL”Windows engineers are supported: WSL follows the Linux paths exactly; native Windows
uses the Windows managed-settings location and PowerShell environment variables
(setx / profile scripts) in place of shell exports. Validate one native-Windows and
one WSL machine as their own fleet profiles in the doctor pass below.
MDM-managed machines
Section titled “MDM-managed machines”Fleet-managed developer machines are supported — flag it at intake and we provide the
managed configuration for your tooling: the
Claude Code managed-settings payload, the
Cursor for Teams bundle, or config files
(~/.codex/config.toml, opencode.json) for your dotfiles/device-management system.
The one failure mode to avoid: MDM policies that block spawning npx will break local
stdio installs — the managed remote-server path exists for exactly that case.
Verification
Section titled “Verification”npx -y @dataworkers/dw-claw@latest doctor on a representative managed machine checks
Node version, registry reachability, client registration, and connector configuration —
run it once on each machine profile (proxied, MDM-managed, VPN-only) before fleet
rollout, and the live connection tests do the
rest.