Skip to content

Add local-dev opt-in for ctx.http.fetch to private/special-purpose addresses #4546

@MichaelHindley

Description

@MichaelHindley

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.rs
      • BLOCKED_HTTP_ADDRESS_ERROR constant
      • FilteredDnsResolver filters resolved IPs via is_blocked_ip(...)
      • blocked ranges include loopback/private/link-local/etc

Reproduction

  1. Run SpacetimeDB locally.
  2. Create a procedure that calls ctx.http.fetch to a local service endpoint (for example http://127.0.0.1:9000/...).
  3. Invoke the procedure.
  4. 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:

  1. spacetime start flag (for local only), e.g. --allow-private-http-egress
  2. Config-based allowlist of hostnames/CIDRs for module HTTP egress
  3. Capability-style per-database/per-module egress policy

Thanks for considering this — this would unblock common local Docker workflows without changing production defaults.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions