PermissionDenied errors despite allow-net=* in Deno Deploy

Direct answer

allow-net=* is not a Deno Deploy runtime permission grant. Deno Deploy does not use Deno CLI --allow-net flags to control user-script outbound access, so the wildcard neither authorizes all hosts nor is the correct place to configure egress. If a script works locally with --allow-net=* but fails in Deploy with PermissionDenied, the problem is almost certainly the destination or API being outside Deploy’s egress policy, not a missing wildcard.

Confirmed facts vs. likely explanation

Confirmed: the Deno CLI treats --allow-net with no allowlist as all network access, and an explicit list is matched per connection. The Deno version installed locally is not the Deno Deploy runtime version; Deploy permission and egress changes are released through the Deploy service or dashboard, not through local deno --version.

Likely explanation: PermissionDenied in Deploy is most often caused by the target or API being outside Deploy’s egress policy. Common exclusions include loopback, RFC1918 private ranges, link-local addresses, and cloud metadata endpoints, which are typically blocked for SSRF protection. Non-HTTP(S) raw sockets and Deno.connect are also commonly restricted. The exact ports, protocols, and current exclusion list depend on the Deploy runtime version and environment.

Steps to resolve this case

1. Capture the full error and identify the target. The Deploy error message and stack should show the failing API and the target scheme, host, and port. This single detail determines whether the block is destination-specific.
2. Verify baseline egress. Deploy a minimal script that only calls fetch('https://example.com/') and logs the status. If that succeeds, public HTTPS egress is enabled and the failure is target- or API-specific. If it fails, the issue is account- or deploy-level egress or runtime version.

   // Minimal Deploy egress test
   export default {
     async fetch() {
       const res = await fetch("https://example.com/");
       return new Response(`status: ${res.status}`);
     },
   };

3. Compare locally and in Deploy by category. Test the same target locally with deno --allow-net and separately in Deploy for public HTTPS, private/loopback, and non-443 port variants. Do not assume localhost, 127.0.0.1, private RFC1918 addresses, link-local addresses, or metadata endpoints are permitted because they work locally.
4. Separate build-time from runtime network access. If the error occurs at deploy/build time while resolving remote imports, treat it as build-time network access. Vendor dependencies or prebundle them rather than expecting a runtime permission flag to fix it.
5. Use an allowed path for restricted targets. If public HTTPS works but the target does not, use an allowed public endpoint or proxy, or request Deploy egress for the specific host and port. Do not rely on allow-net=*.

What not to try

• Do not add --allow-net=* to deployctl, deno.json, or Deploy settings expecting it to override Deploy egress policy; it is not a substitute for an allowed destination.
• Do not generalize from one PermissionDenied; isolate by API (fetch, WebSocket, Deno.connect) and by scheme, host, and port before changing code or contacting support.
• Do not cite a specific Deploy release or version-specific fix without checking the current Deno Deploy documentation or dashboard; behavior can differ between preview, GA, and Subhosting environments.

Missing diagnostic detail

Please provide the exact failing API and target (scheme, host, and port) from the Deploy error stack. This changes the recommendation because a build-time remote import failure, a runtime fetch to a private address, and a raw socket connection each require a different fix.