Server management FAQ

When an order is accepted, its ledger debit and order record are created together. Each requested machine receives a server record in Provisioning state and a queued provisioning request. These states confirm that the workflow was recorded; they do not confirm physical installation or delivery. The server list can show the recorded configuration, region, term, port speed, paid-through time, and lifecycle state.

Connect only after the server is shown as ready and you have a confirmed address and access method for the selected operating system. You may include a supported OpenSSH public key with the order. A root password is not displayed in the server list. On first access, verify host keys, install updates, restrict management access, configure firewall rules, and confirm that backups work.

You can submit reboot and power-off requests for a server that has not been terminated. A Queued message confirms that we received the request; it does not mean the physical operation has finished. Live action history and completion tracking are not available yet. Avoid submitting repeated requests while the first one may still be processing, and keep the returned action reference.

Not yet. There is no customer power-on button or self-service power-on request. A suspended server renewed during its grace period can receive an internal queued power-on request, but this is part of the renewal workflow rather than a dashboard control. A queued state does not confirm physical completion. Use the recovery guidance and the server's recorded state when diagnosing access.

You can request KVM access, but a Queued response only confirms that the request was received. A live browser console, console URL, session token, and completion view are not available yet. IPMI/KVM remains an included service entitlement, but access should not be considered active until a usable console session is provided. Keep ordinary SSH and recovery options prepared where possible.

Treat a reinstall as destructive to local data. Make and verify an independent backup before submitting the request. A Queued response confirms receipt; it does not report progress, successful disk imaging, or a rollback point. Confirm the intended operating system, access method, and recovery plan first. If important data exists only on the server, do not use reinstall as a diagnostic shortcut.

A custom ISO request requires a public HTTPS URL without an embedded username or password. Localhost, private or loopback addresses, link-local destinations, and local domains are rejected. A valid URL can be submitted as a queued mount request, but image download, compatibility, mounting, and completion are not shown yet. Test the media and keep another recovery method available before relying on it.

A root-password rotation request can be queued, but a secure channel for delivering a new password is not available yet. The response confirms receipt of the request only and does not provide a credential. Prefer SSH keys where the operating system supports them. If normal authentication fails, use the documented recovery path instead of assuming that a newly generated password will appear in the dashboard.

Not yet. The service returns an action reference and Queued status when a control request is accepted, but it does not provide a page that shows later progress or completion. Keep the reference for troubleshooting and avoid treating Queued as Finished. The operations guide will describe status tracking once completion events and a customer-visible history are available.

Generated API keys now authenticate read-only requests. The read scope exposes servers and orders; servers exposes servers and network; billing exposes ledger entries. List and revoke keys in the account workspace. Keys cannot place orders, transfer funds, change settings or run server actions. Those operations require an authenticated session and CSRF protection. This local service preview is not a production infrastructure API.