Direct Answer
Deno's --allow-net flag accepts only a comma-separated list of exact host[:port] entries. Wildcards, regex patterns, CIDR ranges, and subdomain matching are not supported in any released version (through 1.46). Every distinct hostname or IP must be enumerated explicitly. Permissions are evaluated at connect/listen time and cannot be modified after process start — changes require a restart.
Confirmed Behavior
- Syntax (Deno ≥ 1.40):
--allow-net=api.example.com,db.example.org:5432 (comma-separated). Older versions require repeating the flag: --allow-net=a.com --allow-net=b.com.
- Exact matching only:
api.example.com does not cover example.com or cdn.example.com.
- Port scoping:
host:443 restricts to that port; omitting the port allows any port on that host.
- IPv6 literals: Must be bracketed:
--allow-net=[::1]:8080.
- Localhost aliases are distinct:
localhost, 127.0.0.1, and [::1] are separate entries.
- Runtime query:
Deno.permissions.query({ name: 'net', host: 'example.com' }) returns { state: 'granted' | 'denied' | 'prompt' }. This is read-only; it cannot grant new hosts.
Practical Automation Strategies
1. Generate the allow-list at deploy time
Keep a canonical source (JSON, YAML, or a small script) listing required hosts. Render it into the startup command during your build or deploy pipeline:
# Example: hosts.json
[
"api.payment.example.com:443",
"db.analytics.example.org:5432",
"metrics.internal:9090"
]
# Build step (bash)
HOSTS=$(jq -r 'join(",")' hosts.json)
den run --allow-net="$HOSTS" server.ts
This avoids manual editing of launch scripts and makes the list auditable in version control.
2. Use a wrapper script for local development
A small shell/JS wrapper can read the same source and invoke Deno, so developers don't maintain two copies:
#!/usr/bin/env bash
# run-dev.sh
HOSTS=$(jq -r 'join(",")' hosts.json)
exec deno run --allow-net="$HOSTS" --watch "$@"
3. Validate the effective list at startup
Log the queried state for each expected host on boot to catch drift early:
for (const host of requiredHosts) {
const { state } = await Deno.permissions.query({ name: 'net', host });
console.log(`[net] ${host}: ${state}`);
}
What Cannot Be Done Today
- Dynamic grants: No API exists to add hosts after startup.
Deno.permissions.request({ name: 'net', host: 'new.example.com' }) will prompt (if running interactively) but cannot succeed in non-interactive environments.
- Pattern matching: No wildcard, regex, or CIDR support. Every subdomain is a separate entry.
- Cost-based throttling: Deno's permission system has no integration with infrastructure cost controls or request budgets.
Outlook
The Deno team has not announced wildcard/regex support for --allow-net in public roadmaps. Discussions in the repo indicate a preference for explicit lists to keep the permission model simple and auditable. If pattern matching is a hard requirement, the current workaround is to generate the explicit list from your service-discovery or config source at deploy time (strategy #1 above).
One Diagnostic Detail
What mechanism currently produces the list of external hosts your workload contacts? (e.g., static config, service discovery, DNS records, a dependency manifest) Knowing this determines whether strategy #1 can be fully automated or requires a custom generator.
denojs