Provisioning, day-to-day operations and the invoices behind them are the same record, so what you bought and what you are running never drift apart.
A provider driver builds it, not a person with a terminal. The workflow runs 20 named steps — region, image, SSH keys, firewall, network, volumes, verification — and the portal shows you which one it is on while it builds.
Run any of them from the portal or the REST API. The 4 marked below are treated as destructive: they need their own permission and you type the operation back before it is accepted, so nobody rebuilds a production box by reflex.
You decide at checkout: your own SSH keys, or a password you set. Keys live in your workspace, can be switched off without being deleted, and are pushed to the provider as part of the build. IPv6 is enabled by default.
An agent is enrolled with the server, and the portal carries its metrics, log sources, alert rules, synthetic checks and maintenance windows. Incidents are raised, acknowledged and resolved in the same place — and metrics, logs and events are on the API too.
Want it sized with you first? [email protected] reaches a person who will do exactly that.
Exactly the resource profile printed on its card: vCPU count, memory, disk and the included transfer allowance. Those figures come from the catalogue row your order will reference, so the card, the cart and the invoice all describe the same server.
However you chose at checkout: your SSH keys, or a password you set. Keys live in your workspace, can be added or switched off at any time, and are pushed to the provider as part of the build. New servers come up with IPv6 enabled.
Yes. A resize is handled as a plan change: it is priced against the target plan, invoiced, and only then applied to the server. A change that has not run yet can still be cancelled from the server's page, so nothing moves until you have seen the figure.
Its provisioning progress while it builds, its snapshots, and the full history of every operation ever queued against it — including the ones that failed and why. Metrics, log sources, alert rules, synthetic checks and incidents sit alongside them, in the portal and on the API.
You cancel from the server's own page, and the window runs from the moment you ask rather than to the end of the term you have paid for. The server keeps running for 7 days, support can still bring it back for another 14 days, and only then is it destroyed at the provider. The exact dates are written onto the service when you confirm.