Scale Up/Down With Configurable Reboot

Configurable reboot lets you change an instance's CPU, memory, and disk size while preserving its filesystem. Under the hood, Morph snapshots the current state and cold‑boots with the new machine configuration, keeping your on‑disk changes (e.g., package installs) intact.

For disk-only changes without restarting applications, see live disk capacity. It has separate eligibility requirements and operation tracking. Configurable reboot keeps its existing restart behavior, including when disk_size is supplied.

TL;DR

• Reboot with new resources, keep the same instance ID and disk contents.
• Great for “burst to build, shrink to serve” workflows.
• Combine with systemd for automatic tasks at boot.

CLI Examples

Scale up to a larger build machine, then scale down for serving.

# Scale UP for builds (16 vCPU, 32 GiB RAM, 64 GiB disk)
morphcloud instance reboot inst_123 \
  --vcpus 16 --memory 32768 --disk-size 65536 \
  -m role=build -m stage=compile

# ... run your build inside the instance ...

# Scale DOWN for deployment (1 vCPU, 2 GiB RAM, 64 GiB disk)
morphcloud instance reboot inst_123 \
  --vcpus 1 --memory 2048 --disk-size 65536 \
  -m role=serve -m stage=run

Optional TTL to avoid lingering on large specs:

# Keep big machine for 30 minutes, then pause
morphcloud instance reboot inst_123 \
  --vcpus 16 --memory 32768 --disk-size 65536 \
  --ttl-seconds 1800 --ttl-action pause

tip

Disk size is specified in MiB. Keep disk size consistent (e.g., 65536) across reboots if you don’t need to change storage.

Python SDK Example

Python

from morphcloud.api import MorphCloudClient

client = MorphCloudClient()
inst = client.instances.get("inst_123")

# Burst to build
inst.reboot(vcpus=16, memory=32_768, disk_size=65_536, metadata={"role": "build"})

# ... run build steps via SSH/exec ...

# Shrink to serve
inst.reboot(vcpus=1, memory=2_048, disk_size=65_536, metadata={"role": "serve"})

Use With systemd

Run setup/build tasks automatically on boot with a one‑shot systemd service.

/etc/systemd/system/app-boot.service

[Unit]
Description=App build/deploy tasks at boot
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=root
WorkingDirectory=/root/app
ExecStart=/usr/local/bin/app-bootstrap.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Enable and test:

chmod +x /usr/local/bin/app-bootstrap.sh
systemctl enable app-boot.service
systemctl start app-boot.service   # run now
# After each configurable reboot, systemd runs it again at boot

Script outline

• Detect role via instance metadata or env (e.g., role=build vs role=serve).
• For build role: pull deps, compile artifacts, populate cache.
• For serve role: run migrations, start supervisor, health checks.

Recommended Workflow

1. Start small (e.g., 1 vCPU / 2 GiB / 64 GiB).

2. When you need to build:

morphcloud instance reboot inst_123 \
  --vcpus 16 --memory 32768 --disk-size 65536 \
  -m role=build

3. Your app-boot.service performs build steps at boot (cache warmup, compile, container image build, etc.).

4. After build completes, shrink back down:

morphcloud instance reboot inst_123 \
  --vcpus 1 --memory 2048 --disk-size 65536 \
  -m role=serve

5. Optionally combine with TTL and wake‑on for cost control:

# Auto-pause while idle and instantly resume on HTTP/SSH
morphcloud instance set-wake-on inst_123 --wake-on-http --wake-on-ssh
morphcloud instance set-ttl inst_123 --ttl-seconds 900 --ttl-action pause

Notes & Guarantees

• Filesystem is preserved: reboot snapshots the current state before restarting with new resources.
• Instance ID remains the same; URLs and service bindings continue to work.
• Resource/billing accounting updates to reflect the new spec after reboot.