Resizing a Resource

You can change the spec of a Cloud VPS, GPU Cloud, or VDS instance - more CPU cores, more RAM, a bigger disk, more included bandwidth - without rebuilding the server from scratch. The portal calls this a resize, and it's the same flow whether you're scaling up for traffic, scaling down to save money, or growing a disk that's filling up.

A resize keeps the same VM - same IPs, same hostname, same disk contents - and just gives it different hardware. CPU and RAM can go up or down; disk can only go up (filesystems can grow but not safely shrink). The portal quotes the cost in real time as you adjust the sliders and charges the prorated difference for the rest of the current cycle.

For metal, you can't resize live - see Dedicated and other categories at the bottom.

• Resize is self-serve for custom-spec VPS configurations and for plans that use tier sliders. Fixed-plan VPS without a slider route to support - the dialog will tell you and route you there.
• You need the Resources role on the team (or be an owner / admin). Read-only members can't resize.
• Resizes  require the VM to be stopped briefly. The dialog tells you upfront if a stop is needed.
• Have a payment method ready if the new spec costs more. Card, PayPal, and crypto all work for resize charges; ACH methods are blocked here.
• If you're growing the disk, plan to grow your guest filesystem afterwards - see What to do after a disk resize.

1. In the sidebar, click the category your resource is in (Cloud, GPU Cloud, or Metal). The list opens.

2. Click the row for the resource you want to resize. The detail page opens at /vps/{id} (or the equivalent path for other categories).

Click on the `Resize VPS` button under Instance Details.

The dialog has two panels:

• Current (top): your existing spec: vCPU count, RAM, disk, bandwidth, current monthly price.
• Target configuration (bottom): sliders for each spec axis. The new monthly price updates live as you drag.

The sliders cover:

1. CPU cores: drag up or down.
2. RAM: drag up or down.
3. Disk: drag up only. The slider's minimum is your current disk size.
4. Bandwidth: drag through the included monthly TB tiers.

The monthly total at the bottom of the panel updates as you drag, so you can see the cost impact before you commit. [5]

After selecting the new specifications of your VM, please hit the Next button.

Below the sliders the dialog calculates one of three outcomes for the rest of the current cycle:

• Immediate charge required: you're moving up in price. The dialog shows the prorated difference for the days remaining in the cycle, plus a payment-method picker.
• Credit will be issued: you're moving down in price (smaller CPU or RAM). A prorated credit posts to your team's account balance.
• No immediate charge: you've swapped roughly equal value (e.g. less CPU for more RAM) or the change is deferred to the next cycle.

If your team has account credit available, tick Apply available credit to use it first. If credits fully cover the charge, no payment method is needed for this resize.

1. Pick a payment method in the picker if an immediate charge applies. Card, PayPal, and crypto are eligible; ACH options are disabled with an explanation.

2. Click the confirm button at the bottom. Its label changes with the situation:

Confirm & Pay $X.X - when an immediate charge applies.

Confirm Resize - when no charge applies.

The dialog runs the resize:

• Card or PayPal: charge runs immediately, resize is applied, the dialog closes, the detail page refreshes with the new spec.
• Crypto (BitPay): opens BitPay's hosted checkout in a new tab. The resize stays pending until BitPay confirms the payment (usually 5–15 minutes); a banner on the detail page tracks the wait, and your resize invoice will reflect a pending payment.

If a power cycle is required, the portal handles it automatically and shows a pending-resize banner until the new config is fully live.

If you grew the disk, the host-side disk is now bigger, but your guest filesystem is still its old size - Linux doesn't auto-grow filesystems. You need to grow it manually inside the server, once.

For Ubuntu / Debian on ext4 (most common):

sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1

For XFS (Rocky / AlmaLinux / Fedora):

sudo growpart /dev/sda 1
sudo xfs_growfs /

Run df -h afterwards to confirm the new size is visible. Adjust the device names if your disk shows up as /dev/vda, /dev/nvme0n1, etc.

Windows resizes the filesystem automatically on boot - no command needed.

If the spec you want is out of stock at your location, or your VPS uses a plan that doesn't support self-serve resize, the dialog hides the confirm button and shows Contact to resize instead.

Clicking it opens a pre-filled support ticket with the spec you wanted. Synteq support takes it from there - typically a couple of business hours for a response.

• The new spec applies immediately (or after the required power cycle).
• The new price appears on your next invoice.
• The detail page now shows the new spec on the hero card and on the Storage tab.
• Bandwidth allowance updates to the new plan's included TB from the next billing cycle.
• The resize is logged under Organization Settings > Activity with the old spec and new spec.

• Traffic is up. More CPU and RAM to keep response times where you want them.
• Disk is filling. Grow the disk before it hits 100% - at 100% the OS can stop accepting writes and applications get unpredictable.
• The workload moved. A server you sized for one job (say, a database) is now running a smaller job - scale down to save money.
• You bought a margin of safety you don't need. Many first-time orders are oversized "just in case." After a few months of stable graphs, scaling down is risk-free.

Resizing is reversible. If you scale down and discover you needed the bigger spec, resize back up the same way. The only one-way axis is disk size.