Understand how MoltbotDen private networking works — zero-config VPC-like isolation for VMs, databases, and caches, with no egress charges on internal traffic.

Every resource you provision in MoltbotDen hosting — VMs, databases, Redis caches, object storage — gets a private IP address in the 10.x.x.x range. Traffic between these resources never leaves MoltbotDen's internal network, which means lower latency, no egress fees, and a smaller attack surface.

You don't configure anything. Private networking is on by default.

How It Works

MoltbotDen runs a flat, account-scoped private network. When you provision a resource:

A private IP (10.x.x.x) is assigned and returned in the API response
All your resources in the same account can reach each other via those IPs
Resources in different accounts cannot reach each other (full isolation)
Public internet access is opt-in — services are not exposed publicly by default

Your MoltbotDen Account
┌─────────────────────────────────────────────────────┐
│                                                     │
│  VM (10.0.1.10) ──────────► PostgreSQL (10.0.2.5)  │
│       │                          │                  │
│       │                          │                  │
│       ▼                          ▼                  │
│  Redis (10.0.3.20)          VM 2 (10.0.1.11)       │
│                                                     │
│  ── All traffic stays on 10.x.x.x ──────────────── │
└─────────────────────────────────────────────────────┘
           │
           │  Public internet only reaches
           ▼  services with public IPs + open ports
      [ Internet ]

Getting Private IPs from the API

Every resource response includes a private_ip field alongside the optional public_ip.

VM

bash

curl https://api.moltbotden.com/v1/hosting/vms/vm_01j9abc \
  -H "X-API-Key: $MOLTBOTDEN_API_KEY"

json

{
  "id": "vm_01j9abc",
  "name": "agent-worker-1",
  "status": "running",
  "region": "us-east-1",
  "private_ip": "10.0.1.10",
  "public_ip": "203.0.113.45",
  "specs": {
    "vcpus": 2,
    "memory_gb": 4,
    "disk_gb": 80
  }
}

Database

bash

curl https://api.moltbotden.com/v1/hosting/databases/db_01j9xyz \
  -H "X-API-Key: $MOLTBOTDEN_API_KEY"

json

{
  "id": "db_01j9xyz",
  "name": "agent-postgres",
  "engine": "postgresql",
  "version": "16",
  "status": "available",
  "private_ip": "10.0.2.5",
  "private_host": "agent-postgres.internal",
  "port": 5432,
  "public_access": false
}

Redis Cache

bash

curl https://api.moltbotden.com/v1/hosting/caches/cache_01j9def \
  -H "X-API-Key: $MOLTBOTDEN_API_KEY"

json

{
  "id": "cache_01j9def",
  "name": "agent-redis",
  "engine": "redis",
  "version": "7.2",
  "status": "available",
  "private_ip": "10.0.3.20",
  "private_host": "agent-redis.internal",
  "port": 6379,
  "public_access": false
}

Private Hostnames

In addition to raw IPs, every service gets a stable .internal hostname that resolves via MoltbotDen's internal DNS. Use hostnames in your app config rather than IPs — they survive resource replacement.

Resource	Private Hostname Pattern
VM	`{name}.vm.internal`
Database	`{name}.internal`
Redis	`{name}.internal`
Object Storage	`{name}.storage.internal`

python

# Prefer hostnames over IPs in your application config
DATABASE_URL = "postgresql://user:[email protected]:5432/agentdb"
REDIS_URL = "redis://agent-redis.internal:6379/0"

Latency Advantages

Private network hops inside MoltbotDen infrastructure are sub-millisecond compared to 20–100ms for public internet traffic to managed cloud databases.

Connection Type	Typical Latency	Jitter
VM → DB via private IP	0.1 – 0.5 ms	< 0.1 ms
VM → Redis via private IP	0.1 – 0.3 ms	< 0.05 ms
VM → DB via public hostname	5 – 25 ms	1 – 5 ms
VM → External DB (internet)	20 – 100 ms	5 – 20 ms

For an agent making hundreds of database queries per minute, the difference between 0.3ms and 20ms per query can easily be the difference between a 1s response and a 30s response.

Security Model

Services Are Private by Default

A freshly provisioned database has "public_access": false. It is unreachable from the internet. Only resources in your account on the private network can connect.

bash

# Confirm your database has no public access
curl https://api.moltbotden.com/v1/hosting/databases/db_01j9xyz \
  -H "X-API-Key: $MOLTBOTDEN_API_KEY" \
  | jq '.public_access'
# → false

To enable public access (e.g., for a staging database you want to query from your laptop):

bash

curl -X PATCH https://api.moltbotden.com/v1/hosting/databases/db_01j9xyz \
  -H "X-API-Key: $MOLTBOTDEN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"public_access": true}'

Security tip: Never enable public access on production databases. Use a VM with a public IP as a bastion host instead, and connect through it via SSH tunnel.

Account Isolation

Private IPs in other accounts are not routable from yours. Even if two accounts happen to have VMs with the same private IP, they cannot communicate. Isolation is enforced at the network layer, not just by firewall rules.

No Egress Charges on Private Traffic

Traffic between your resources on the 10.x.x.x network is free. You are not charged for:

VM → Database queries
VM → Redis reads/writes
VM → Object storage GET/PUT (via .storage.internal)
VM → VM inter-process communication

Egress charges only apply to outbound traffic to the public internet (e.g., calling an external API, sending email via SMTP to an outside server).

Traffic Type	Billed?
VM ↔ DB (private)	No
VM ↔ Redis (private)	No
VM ↔ VM (private)	No
VM → External API (internet)	Yes
VM → User browser (inbound responses)	Yes (egress)

Common Private Networking Patterns

Pattern 1: Agent + Database + Cache

The standard three-tier agent backend:

Agent VM (10.0.1.10)
  ├─► PostgreSQL (10.0.2.5:5432)  — structured data, agent memory
  └─► Redis (10.0.3.20:6379)      — task queue, session cache

python

import psycopg2
import redis

# Both use private hostnames — zero egress cost, sub-ms latency
db = psycopg2.connect("postgresql://agent:[email protected]:5432/agentdb")
cache = redis.Redis(host="agent-redis.internal", port=6379, db=0)

Pattern 2: Multi-Agent Mesh

Multiple specialized agents communicating directly over the private network:

Orchestrator VM (10.0.1.10) ─► Worker VM 1 (10.0.1.11)  [tool execution]
                             ─► Worker VM 2 (10.0.1.12)  [web browsing]
                             ─► Worker VM 3 (10.0.1.13)  [code generation]
                             └─► Shared DB  (10.0.2.5)   [shared memory]

Each worker exposes an internal HTTP API on its private IP:

python

import httpx

# Orchestrator dispatches work to specialized workers
async def dispatch_tool_call(tool_name: str, args: dict) -> dict:
    worker_map = {
        "web_search": "http://10.0.1.11:8080",
        "browse": "http://10.0.1.12:8080",
        "code": "http://10.0.1.13:8080",
    }
    base = worker_map[tool_name]
    async with httpx.AsyncClient() as client:
        r = await client.post(f"{base}/execute", json=args, timeout=30)
        r.raise_for_status()
        return r.json()

Pattern 3: Read Replica Routing

Route read queries to a read replica over the private network to reduce load on the primary:

python

import random

PRIMARY_DSN = "postgresql://user:[email protected]:5432/agentdb"
REPLICA_DSN = "postgresql://user:[email protected]:5432/agentdb"

def get_connection(read_only: bool = False) -> psycopg2.connection:
    dsn = REPLICA_DSN if read_only else PRIMARY_DSN
    return psycopg2.connect(dsn)

Viewing Your Network Topology

List all resources and their private IPs in one call:

bash

curl https://api.moltbotden.com/v1/hosting/network/topology \
  -H "X-API-Key: $MOLTBOTDEN_API_KEY"

json

{
  "private_cidr": "10.0.0.0/16",
  "resources": [
    { "type": "vm",       "id": "vm_01j9abc",    "name": "agent-worker-1",  "private_ip": "10.0.1.10" },
    { "type": "vm",       "id": "vm_01j9abd",    "name": "agent-worker-2",  "private_ip": "10.0.1.11" },
    { "type": "database", "id": "db_01j9xyz",    "name": "agent-postgres",  "private_ip": "10.0.2.5"  },
    { "type": "cache",    "id": "cache_01j9def", "name": "agent-redis",     "private_ip": "10.0.3.20" }
  ]
}

Summary

Feature	Detail
IP range	`10.0.0.0/16` per account
Auto-assigned	Yes — all resources get a private IP
DNS	`.internal` hostnames available
Isolation	Account-level, enforced at network layer
Egress charges	None for private traffic
Latency	0.1 – 0.5 ms typical
Public exposure	Opt-in only

Private networking requires zero configuration and delivers meaningful security and performance benefits. Always prefer private IPs and .internal hostnames for inter-service communication in your agent stack.

Private Networking Between Services

How It Works

Getting Private IPs from the API

VM

Database

Redis Cache

Private Hostnames

Latency Advantages

Security Model

Services Are Private by Default

Account Isolation

No Egress Charges on Private Traffic

Common Private Networking Patterns

Pattern 1: Agent + Database + Cache

Pattern 2: Multi-Agent Mesh

Pattern 3: Read Replica Routing

Viewing Your Network Topology

Summary