Account user guide
Two accounts, created together
Section titled “Two accounts, created together”Signing up gives you a site login. Onboarding turns that into a cloud tenancy. They are separate systems and they do not share a session.
| Site login | Cloud login | |
|---|---|---|
| You are | Your email address | cust-<your user id> |
| Credential | Password, then a short-lived token | A separate cloud password, plus access keys |
| Opens | This site, billing, the account API | Every cloud API, both consoles |
You will end up holding two passwords. That is not a mistake in the design; it is one identity system for the shop and a different one for the cloud.
What onboarding creates
Section titled “What onboarding creates”POST /v1/onboard — the button in the console — makes five things true, in
order, recording each before moving to the next:
- A billing customer, tagged with your tenant name.
- A subscription on the metered price, invoiced with 30 days to pay.
- A project — your tenancy, the boundary everything you own lives inside.
- A network of your own — network, subnet (
10.200.0.0/24) and router. Without it a launch would have nothing to attach a machine to. - A cloud user in that project, granted the
memberrole and a starting quota.
Because each step is recorded before the next begins, a half-finished onboarding — a crash, a timeout, an upstream error — is finished by pressing the button again rather than by starting over.
[!warning]
The cloud password is used only the first time. Calling onboarding again with a different password does not change it, and there is no password-reset endpoint for it yet. Choose it once and store it somewhere you will still have it in six months.
It is also kept in recoverable form so the console can be opened for you without asking. Use a password you use nowhere else, and read Credentials and trust.
Verified email is required
Section titled “Verified email is required”Onboarding refuses an unverified email address. Verify before you press it.
Your first credentials
Section titled “Your first credentials”Everything against the compute API needs an access key pair, which is not your password. Mint one in the console’s Access keys view, or with one API call.
Full detail — including that reading the list returns the secret, not just the key id — is in Access keys.
What one account gets you
Section titled “What one account gets you”| Projects | One |
| Cloud users | One |
| Roles | One — member, on your own project |
| Networks | One, created for you |
| Starting quota | 4 vCPU, 8 GB RAM |
| Storage quota | Not set — see Quotas and limits |
One account is one boundary. You cannot make a second user for a colleague, cannot issue a read-only credential, and cannot separate staging from production inside it. If you need two environments that cannot touch each other, sign up twice.
Raising a quota is a conversation, not a form: there is no self-service quota API.
Where the bill lives
Section titled “Where the bill lives”There is no billing screen of ours. The account API hands you a link into the payment provider’s hosted portal, and that is where usage, invoices and payment method live.
Two things worth knowing:
- Only compute is billed. Storage, snapshots, egress and addresses are not rated today. That is a gap, not a discount.
GET /v1/usageis the one place to see what is running and what the month has cost so far, before an invoice exists.
Getting in when something is wrong
Section titled “Getting in when something is wrong”- Web console — the whole cloud in a browser, signed in with your cloud credentials.
- Machine console — a graphical console attached to one machine, which works before its network does.
Neither has MFA; the cloud password is the only factor. See Web console and VNC.