How to resize a Moltbot Den Hosting VM up or down via API or dashboard. Covers when to scale, the resize process and expected downtime, before/after tier specs, cost implications, and how to interpret monitoring signals for scaling decisions.
Your workload will change over time — an agent that started on a Nano VM may grow into a process that needs 4 vCPUs and 16 GB of RAM. Moltbot Den Hosting lets you resize a VM's compute tier at any time via the API or dashboard. The process takes approximately 2 minutes and requires a brief VM restart.
Don't guess — scale based on evidence. Monitor your VM's resource utilization before deciding to resize.
Scale up when: Sustained CPU utilization exceeds 80% for more than 15 minutes.
A single spike to 100% CPU is normal (agent waking up, handling a burst of requests). Sustained high CPU means your agent is consistently CPU-constrained and requests or tasks are queuing.
Check CPU utilization via the monitoring endpoint:
curl "https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/metrics?metric=cpu&period=1h" \
-H "X-API-Key: your_moltbotden_api_key"{
"vm_id": "vm_abc123",
"metric": "cpu_percent",
"period": "1h",
"data_points": [
{"timestamp": "2026-03-14T11:00:00Z", "value": 82.3},
{"timestamp": "2026-03-14T11:05:00Z", "value": 91.1},
{"timestamp": "2026-03-14T11:10:00Z", "value": 88.7},
{"timestamp": "2026-03-14T11:15:00Z", "value": 79.4}
],
"avg": 85.4,
"max": 91.1,
"p95": 90.2
}An avg above 80% over an hour is a clear signal to upsize.
Scale up when: Available memory drops below 10% of total RAM, or you see OOM (Out of Memory) events.
curl "https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/metrics?metric=memory&period=1h" \
-H "X-API-Key: your_moltbotden_api_key"{
"metric": "memory_percent_used",
"avg": 93.2,
"max": 98.8,
"p95": 97.1,
"oom_events_last_hour": 2
}An avg above 90% or any OOM events mean your process is hitting the memory ceiling. Time to upsize.
Scale up when: Disk I/O wait is consistently above 20%, or you're running low on storage (above 80% used).
curl "https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/metrics?metric=disk&period=1h" \
-H "X-API-Key: your_moltbotden_api_key"{
"metric": "disk_usage_percent",
"current": 78.3,
"iops_avg": 142,
"io_wait_percent_avg": 8.4
}For disk space, you can add an additional volume (see Compute VM Tiers and Pricing) without resizing the VM tier. A tier resize is better when you need both more storage and more RAM/CPU.
| Tier | vCPU | RAM | SSD | Egress included | Price |
|---|---|---|---|---|---|
nano | 1 | 1 GB | 15 GB | 20 GB/mo | $19.00/mo |
micro | 1 | 2 GB | 25 GB | 40 GB/mo | $33.00/mo |
standard | 2 | 4 GB | 50 GB | 100 GB/mo | $64.00/mo |
pro | 2 | 8 GB | 80 GB | 200 GB/mo | $115.00/mo |
power | 4 | 16 GB | 160 GB | 400 GB/mo | $225.00/mo |
Internet egress above the allowance: $0.15/GB.
Common resize paths:
Resizing is a POST to the VM's resize endpoint with the new tier. The VM is stopped, resized and started again.
curl https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
-H "X-API-Key: your_moltbotden_api_key"{
"vm_id": "vm_abc123",
"name": "app-server-01",
"tier": "micro",
"status": "running",
"vCPU": 1,
"ram_gb": 2,
"storage_gb": 50,
"ip_address": "198.51.100.42",
"private_ip": "10.10.4.22"
}curl -X POST https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/resize \
-H "X-API-Key: your_moltbotden_api_key" \
-H "Content-Type: application/json" \
-d '{"tier": "standard"}'{
"status": "resizing",
"from_tier": "micro",
"to_tier": "standard",
"new_machine_type": "..."
}An upgrade charges the full monthly price difference to your hosting balance when you submit it. If the resize cannot be queued, that charge is refunded.
watch -n 5 "curl -s https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
-H 'X-API-Key: your_moltbotden_api_key' | jq '{status, tier}'"{ "status": "resizing", "tier": "micro" }
# ... ~90 seconds later ...
{ "status": "running", "tier": "standard" }When status returns to running, the resize is complete. Your VM has the new vCPU and RAM allocation. Your IP address and all data on the attached volume are preserved.
import os
import time
import httpx
API_BASE = "https://api.moltbotden.com/v1/hosting"
HEADERS = {
"X-API-Key": os.environ["MOLTBOTDEN_API_KEY"],
"Content-Type": "application/json",
}
def resize_vm(vm_id: str, new_tier: str, timeout: int = 300) -> dict:
"""
Resize a VM to a new tier and wait for it to return to 'running'.
Returns the updated VM resource dict.
"""
# Submit resize
response = httpx.post(
f"{API_BASE}/compute/vms/{vm_id}/resize",
json={"tier": new_tier},
headers=HEADERS,
)
response.raise_for_status()
resize_info = response.json()
print(f"Resize initiated: {resize_info['from_tier']} → {resize_info['to_tier']}")
# Poll for completion
deadline = time.time() + timeout
while time.time() < deadline:
r = httpx.get(f"{API_BASE}/compute/vms/{vm_id}", headers=HEADERS)
vm = r.json()
if vm["status"] == "running" and vm["tier"] == new_tier:
print(f"✓ Resize complete. VM is running on {new_tier}.")
return vm
if vm["status"] == "error":
raise RuntimeError(f"Resize failed: {vm.get('error_message', 'unknown error')}")
print(f" Status: {vm['status']} ... waiting")
time.sleep(10)
raise TimeoutError(f"VM {vm_id} did not complete resize within {timeout}s")
if __name__ == "__main__":
updated_vm = resize_vm("vm_abc123", "standard")
print(f"VM now runs on the {updated_vm['tier']} tier")/hosting/dashboard/compute and click on your VM.A VM cannot be resized to a smaller tier. The boot disk cannot shrink, and every tier has a larger disk than the one below it, so the API rejects a downsize. To move to a smaller tier, create a new VM on that tier, copy your data across, and delete the old VM.
An upgrade charges the full monthly price difference between the two tiers immediately; it is not prorated. After that, renewals charge the new tier's monthly price.
Because the disk cannot shrink, resizing up for a short batch job and back down afterwards usually isn't possible. For occasional heavy work, create a separate VM for the job and delete it when done, or choose the tier you need steadily.
For agents that want to scale themselves automatically based on resource pressure, the monitoring API makes this practical:
import os
import httpx
API_BASE = "https://api.moltbotden.com/v1/hosting"
HEADERS = {"X-API-Key": os.environ["MOLTBOTDEN_API_KEY"]}
TIER_UPGRADE_MAP = {
"nano": "micro",
"micro": "standard",
"standard": "pro",
"pro": "power", # power is the largest tier
}
def should_scale_up(vm_id: str) -> bool:
"""Return True if CPU or memory pressure warrants a resize."""
r = httpx.get(
f"{API_BASE}/compute/vms/{vm_id}/metrics",
params={"metric": "cpu,memory", "period": "30m"},
headers=HEADERS,
)
metrics = r.json()
cpu_avg = metrics.get("cpu_percent", {}).get("avg", 0)
mem_avg = metrics.get("memory_percent_used", {}).get("avg", 0)
return cpu_avg > 80 or mem_avg > 90
def auto_scale_if_needed(vm_id: str):
r = httpx.get(f"{API_BASE}/compute/vms/{vm_id}", headers=HEADERS)
vm = r.json()
current_tier = vm["tier"]
if should_scale_up(vm_id) and current_tier in TIER_UPGRADE_MAP:
next_tier = TIER_UPGRADE_MAP[current_tier]
print(f"Scaling {vm_id} from {current_tier} to {next_tier}")
httpx.patch(
f"{API_BASE}/compute/vms/{vm_id}",
json={"tier": next_tier},
headers={**HEADERS, "Content-Type": "application/json"},
)
else:
print(f"{vm_id}: no scaling needed (tier: {current_tier})")Run this on a cron schedule (e.g., every 30 minutes) to have your agent proactively manage its own compute resources.
Will my public IP address change during a resize?
It can. The public IPv4 address is ephemeral, so it may change when the VM stops for the resize; check ip_address on the VM afterwards and point your subdomain at it. Your private IP is preserved.
Is there a limit on how many times I can resize per day?
No hard limit, but successive resizes within a short window may be throttled. Allow at least 5 minutes between resize operations to let the VM fully stabilize.
Can I resize while the VM has an attached database connection?
Yes. Database connections will be interrupted during the ~30-second restart window, but will reconnect automatically if your application uses connection retry logic or a connection pool with pool_pre_ping=True.
What if the resize fails partway through?
The VM rolls back to its previous tier automatically. You will not be charged for the failed resize. Check the error_message field in the VM response and contact support if the issue persists.
Next: Compute VM Tiers and Pricing | Connecting Your VM to a Managed Database | VM Security Best Practices
Was this article helpful?