All updates

VPS Fixes: Up-Front Capacity Checks and Accurate Power States

A VPS order is now accepted only when there is room for it, a stopped VPS stays stopped, and a failed deployment says why.

Version 2.9.147Bug fixVPS

What's changed

  • Ordering a VPS now reserves a server and, unless you chose IPv6 only, an IPv4 address before the order is accepted. When there is no room, the console and POST /api/v1/vps answer with a 422 on resource_profile and nothing is created, instead of accepting the order and leaving it in Creating with no explanation. Orders sent at the same moment wait up to 10 seconds for their turn, and are then told to try again shortly, and the create page and GET /api/v1/vps/plans now read the free IPv4 addresses live
  • An order for a plan that is currently sold out on the processor and datacenter you chose is refused up front, in the console and in POST /api/v1/vps, instead of being accepted and failing afterwards. The message says the plan is temporarily unavailable due to capacity, or that we are at capacity for new VPS servers in that datacenter when every plan or every IPv4 address is gone
  • A VPS you stop stays Stopped. Before, a routine deployment status update could turn a stopped VPS back to Running a few seconds later, which also blocked deleting it; the status now follows the VM's real power state
  • Reboot now asks the VPS to restart in one step, instead of switching it off and on again through two configuration changes made back to back. A failed Start, Stop or Reboot leaves the VPS in the state it is really in and sends you a notification naming the action, and a firewall change that is still being applied stays Applying, with a retry hint if it cannot be confirmed, instead of showing Error
  • A volume now shows Attached only after the running VPS has the disk. A volume created while its VPS is still provisioning waits for it, checking every 30 seconds for up to 30 minutes before it shows Failed, where it could show Attached without the disk ever reaching the VPS. The button and the status now read Delete volume, Deleting and Deleted, because removing a volume has always deleted it and its data; the API keeps its detaching and detached status values
  • A VPS that fails to deploy now says why: status_details.error and GET /api/v1/vps/{id}/diagnose (the vps_diagnose tool in the MCP server) return the code vps.capacity_unavailable or vps.deployment_failed with a message that is safe to show, where they used to give an error status with no explanation. The events list stays empty until a VM exists, because it shows only real platform events