Skip to main content
Start with the Runloop Quickstart to use the examples below.
Network Policies allow you to control what network resources your Devboxes can access. By default, Devboxes have unrestricted network access. Network Policies let you restrict egress traffic to specific hostnames, block all external access, or allow communication between your Devboxes.

Why Use Network Policies?

Network Policies are essential for:
  • Security: Limit network access to only the services your AI agent needs (e.g., specific APIs, package registries)
  • Compliance: Ensure Devboxes can only communicate with approved endpoints
  • Cost Control: Prevent unexpected network charges from unrestricted access
  • Isolation: Control whether Devboxes can communicate with each other

Network Policy Configuration

A Network Policy defines egress rules with the following options:

Hostname Wildcards

You can use wildcards in the first label of hostnames:
  • github.com - Allow only github.com
  • *.github.com - Allow all subdomains of github.com
  • *.npmjs.org - Allow all subdomains of npmjs.org

Limits

You can create up to 100 network policies per account. If you need more, please contact support@runloop.ai.

Creating a Network Policy

Policy Types

Allow All (Default Behavior)

Allows unrestricted network access:

Deny All

Block all external network access by setting allow_all=False with an empty hostname list:

Allow Specific Hosts

Restrict access to only the services your agent needs:

Allow Devbox-to-Devbox Communication

Enable traffic between your Devboxes via tunnels:

Allow Agent Gateway and MCP Hub Access

When using Agent Gateways or MCP Hub with a restrictive network policy, you must explicitly enable access to those services. These are dedicated toggles — you do not need to add Runloop hostnames to allowed_hostnames.
If allow_all is true, Agent Gateway and MCP Hub access are automatically permitted. These toggles only matter when allow_all is false.

Applying Network Policies

Network policies can be applied at multiple levels:

Apply to a Devbox

Apply a policy when creating a Devbox using network_policy_id inside launch_parameters:

Apply to a Blueprint

Blueprints support two types of network policy application:
  1. Build-time policy (network_policy_id at top level): Restricts network access during the blueprint build process
  2. Runtime policy (launch_parameters.network_policy_id): Applies to all Devboxes created from the blueprint
See the Blueprints network policies documentation for more details on using network policies with blueprints.

Override Blueprint Policy

When creating a Devbox from a Blueprint, you can override the inherited runtime policy:

Managing Network Policies

List Policies

Get Policy Details

Update a Policy

When you update a network policy, all running Devboxes and Blueprints using that policy will be updated. Changes are eventually consistent and may take a few moments to propagate to all resources.

Delete a Policy

You cannot delete a network policy that is currently in use by any Devboxes or Blueprints. Remove the policy from all resources before deleting it.

Common Use Cases

AI Agent with API Access

Allow access to code repositories, package registries, and Runloop services (Agent Gateway for LLM API proxying, MCP Hub for tool access):

Multi-Devbox Workflow

Allow Devboxes to communicate with each other for distributed workloads:

Best Practices

  1. Start Restrictive: Begin with a deny-all policy and add only the hosts your agent needs.
  2. Use Wildcards Carefully: *.example.com allows all subdomains, which may be broader than intended.
  3. Name Policies Descriptively: Use names that indicate the policy’s purpose (e.g., ai-agent-production, eval-restricted).
  4. Document Policies: Use the description field to document why specific hosts are allowed.
  5. Audit Regularly: Review policies periodically to remove unnecessary access.
  6. Use Blueprint Inheritance: Apply policies to Blueprints for consistent security across Devboxes.
  7. Test Policies: Before deploying to production, test that your agent can access all required services.