-
Notifications
You must be signed in to change notification settings - Fork 827
Description
Summary
When running SpacetimeDB locally, ctx.http.fetch rejects requests to private/special-purpose addresses (for example local
Docker services like MinIO on 127.0.0.1:9000 or 192.168.x.x), returning:
refusing to connect to private or special-purpose addresses
This blocks legitimate local-development setups where a module needs to call an object-storage service running on the same
machine/network, like in my case a S3 api compatible storage container.
Evidence
- Runtime log:
ProcedureHttpRequest returned errno: 21 (The HTTP request failed)- Error message:
refusing to connect to private or special-purpose addresses
- Source references:
crates/core/src/host/instance_env.rsBLOCKED_HTTP_ADDRESS_ERRORconstantFilteredDnsResolverfilters resolved IPs viais_blocked_ip(...)- blocked ranges include loopback/private/link-local/etc
Reproduction
- Run SpacetimeDB locally.
- Create a procedure that calls
ctx.http.fetchto a local service endpoint (for examplehttp://127.0.0.1:9000/...). - Invoke the procedure.
- Observe failure with the blocked-address error above.
Why this matters
This is a sensible default for production SSRF protection, but local development often relies on Docker-local services and
private network addresses. There is currently no documented local-dev override.
Requested behavior
Add an explicit opt-in local-dev override so private/special-purpose address egress can be enabled intentionally during
local development only.
Possible safe designs:
spacetime startflag (for local only), e.g.--allow-private-http-egress- Config-based allowlist of hostnames/CIDRs for module HTTP egress
- Capability-style per-database/per-module egress policy
Thanks for considering this — this would unblock common local Docker workflows without changing production defaults.