Deployments · Networking

Networking

Control who can reach your service on its public URL. Open to the world by default, locked to an IP allowlist when you need it — staging environments, partner integrations, office-only tools.

Two modes

Mode	Reachable from	Use it for
Public (default)	Anywhere on the internet	Production APIs, customer-facing apps, anything meant to be public.
Restricted	Only IPs and CIDR ranges you allowlist	Staging, internal tools, partner-only APIs, services that haven't shipped yet.

Public is the default the moment you deploy. Switching to Restricted takes effect on the next deployment.

Configure access

Make a service public (the default — only run this if you previously restricted it):

$ csph services set-network --type public

Restrict access to specific IPs and CIDR ranges:

$ csph services set-network --type restricted --allow 203.0.113.42 --allow 10.0.0.0/8 --allow 2001:db8::/32

Add or remove allowlist entries without rewriting the whole list:

$ csph services allow 203.0.113.99

$ csph services revoke 203.0.113.42

What "restricted" means in practice

• Requests from non-allowlisted IPs receive HTTP 403. See the error catalog for the response shape.
• The allowlist applies to the public hostname (e.g. silver-cobra.computesphere.app) AND every custom domain attached to the service.
• Health checks, the rollout system, and platform monitoring are not blocked — those flow through internal paths, not the public URL.
• Webhooks from third parties (Stripe, GitHub, etc.) work IF you allowlist the provider's IP ranges. Each provider publishes their own list.

Allowlist limits

• Entries per service: 200 combined IPv4 / IPv6 / CIDR.
• CIDR depth: any /X range your provider issues.
• Wildcards: not supported. Use CIDR ranges instead.

Restricted vs. private network

Restricted access is the right tool when you need to gate a service from the public internet but the consumers are themselves outside ComputeSphere (your office, partner orgs, a fixed bastion).

If the consumers are other ComputeSphere services in the same project, use the private network — services reach each other over an internal DNS name without ever touching the public internet, and the allowlist becomes irrelevant.

Next

• Custom domains — point your own hostname at the service, TLS issued automatically
• Private network — service-to-service inside your project without touching the public internet
• Lifecycle — what happens to network config across deploys and rollbacks