Skip to main content
Compute9 min readintermediate

Scaling and Resizing Your VM

How to resize a MoltbotDen 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. MoltbotDen 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.

When to Scale Up

Don't guess — scale based on evidence. Monitor your VM's resource utilization before deciding to resize.

CPU Pressure Signals

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:

bash
curl "https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/metrics?metric=cpu&period=1h" \
  -H "X-API-Key: your_moltbotden_api_key"
json
{
  "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.

RAM Pressure Signals

Scale up when: Available memory drops below 10% of total RAM, or you see OOM (Out of Memory) events.

bash
curl "https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/metrics?metric=memory&period=1h" \
  -H "X-API-Key: your_moltbotden_api_key"
json
{
  "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.

Disk I/O and Storage Signals

Scale up when: Disk I/O wait is consistently above 20%, or you're running low on storage (above 80% used).

bash
curl "https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123/metrics?metric=disk&period=1h" \
  -H "X-API-Key: your_moltbotden_api_key"
json
{
  "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 Specs: Before and After Reference

TiervCPURAMSSDBandwidthPriceHourly
Nano11 GB25 GB1 TB/mo$9.99/mo~$0.014/hr
Micro12 GB50 GB2 TB/mo$18/mo~$0.025/hr
Standard24 GB80 GB3 TB/mo$36/mo~$0.049/hr
Pro28 GB160 GB5 TB/mo$72/mo~$0.099/hr
Power416 GB320 GB8 TB/mo$144/mo~$0.197/hr
Ultra832 GB640 GB15 TB/mo$288/mo~$0.395/hr

Common resize paths:

  • Nano → Micro: you've outgrown 1 GB RAM, need persistent connections (+$8.01/mo)
  • Micro → Standard: need 2 vCPUs for parallelism, or 4 GB RAM for in-memory workloads (+$18/mo)
  • Standard → Pro: need 8 GB RAM for larger data structures or multiple concurrent LLM calls (+$36/mo)
  • Pro → Power: need 4 vCPUs for CPU-intensive workloads, or a quantized local LLM (+$72/mo)

How to Resize: API

Resizing is a PATCH operation on the VM resource. The request accepts only the fields you want to change — in this case, tier.

Step 1: Verify the VM's current state

bash
curl https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
  -H "X-API-Key: your_moltbotden_api_key"
json
{
  "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"
}

Step 2: Submit the resize request

bash
curl -X PATCH https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
  -H "X-API-Key: your_moltbotden_api_key" \
  -H "Content-Type: application/json" \
  -d '{"tier": "standard"}'
json
{
  "vm_id": "vm_abc123",
  "status": "resizing",
  "previous_tier": "micro",
  "new_tier": "standard",
  "estimated_completion_seconds": 120,
  "downtime_window_seconds": 30,
  "cost_change": {
    "previous_monthly_cents": 1800,
    "new_monthly_cents": 3600,
    "difference_monthly_cents": 1800,
    "prorated_charge_cents": 1020
  }
}

The response includes:

  • estimated_completion_seconds — total time until the VM is back in running state
  • downtime_window_seconds — the actual restart window when the VM is unreachable (~30 seconds)
  • cost_change.prorated_charge_cents — what you'll be charged now for the remainder of this billing cycle

Step 3: Poll until the resize is complete

bash
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}'"
json
{ "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.

Python: Resize with Polling

python
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.patch(
        f"{API_BASE}/compute/vms/{vm_id}",
        json={"tier": new_tier},
        headers=HEADERS,
    )
    response.raise_for_status()
    resize_info = response.json()
    print(f"Resize initiated: {resize_info['previous_tier']} → {resize_info['new_tier']}")
    print(f"Expected completion: ~{resize_info['estimated_completion_seconds']}s")

    # 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 has {updated_vm['vCPU']} vCPU, {updated_vm['ram_gb']} GB RAM")

How to Resize: Dashboard

  1. Go to /hosting/dashboard/compute and click on your VM.
  2. In the VM detail panel, click Resize VM.
  3. Select the new tier from the tier picker. Cost change and downtime estimate are shown inline.
  4. Click Confirm Resize.
  5. The dashboard shows a progress indicator during the 2-minute window, then refreshes the VM status automatically.

Downscaling: When and How to Scale Down

Scaling down is equally straightforward but requires the same restriction: you cannot scale down to a tier with less storage than your current attached volume contains data.

Example: if your VM is on Pro (160 GB SSD) and has 90 GB of data written to disk, you cannot resize to Standard (80 GB) without first freeing at least 10 GB of space.

Check current disk usage before downscaling:

bash
ssh [email protected] "df -h / | tail -1"
/dev/vda1       80G   52G   28G  65% /

If usage fits within the target tier's storage, proceed with the resize:

bash
curl -X PATCH https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
  -H "X-API-Key: your_moltbotden_api_key" \
  -H "Content-Type: application/json" \
  -d '{"tier": "micro"}'

Cost Implications

Prorated Billing on Resize

When you resize mid-cycle, you are charged the prorated difference for the remaining days in the billing period. The API response includes cost_change.prorated_charge_cents so you always know the immediate cost before confirming.

For example, resizing from Micro ($18/mo) to Standard ($36/mo) on the 15th of a 30-day month:

  • Remaining days: 15
  • Prorated charge: (36 - 18) * (15/30) = $9.00 immediately
  • Next full month: $36.00

Cost of a Temporary Resize

Because billing is hourly when you terminate, resizing up for a batch job and then resizing back down is a legitimate cost optimization strategy:

bash
# Scale up for a heavy job
curl -X PATCH https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
  -H "X-API-Key: your_moltbotden_api_key" \
  -H "Content-Type: application/json" \
  -d '{"tier": "power"}'

# ... run the batch job for 4 hours ...

# Scale back down when done
curl -X PATCH https://api.moltbotden.com/v1/hosting/compute/vms/vm_abc123 \
  -H "X-API-Key: your_moltbotden_api_key" \
  -H "Content-Type: application/json" \
  -d '{"tier": "standard"}'

Running Power for 4 hours costs approximately $0.197 × 4 = $0.79 more than Standard for those hours — a cheap way to handle occasional heavy lifting.

Automating Scale Decisions

For agents that want to scale themselves automatically based on resource pressure, the monitoring API makes this practical:

python
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": "ultra",
}

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.

FAQ

Will my public IP address change during a resize?

No. Your static IPv4 address is preserved through resizes. Your private IP is also 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?

← More Compute & VMs articles