Organizations
Every instance you deploy, every credit you spend and every template you save belongs to an organization. Nothing on Superheat is owned by a user directly.
You have one from the moment you sign in, so this rarely gets in your way — until you join a second organization, and suddenly the balance and the instance list are not the ones you remember.
Your personal organization
The first time you sign in, a personal organization is created for you and you are its admin. It is a normal organization in every respect except one: it cannot have members. To work with other people, create a separate organization and invite them there.
The console shows the active organization in the switcher; the API takes it as the X-Org-Id header. When that header is absent, requests act on your personal organization.
Roles
There are two roles, per organization. The same person can be an admin in one and a member in another.
| Action | Admin | Member |
|---|---|---|
| Browse offers, deploy, stop, start, destroy | yes | yes |
| Create and edit the organization's templates | yes | yes |
| Read the balance, transactions and usage log | yes | yes |
| Create a personal API key, and revoke their own | yes | yes |
| Create or revoke team API keys | yes | no |
| Add credits | yes | no |
| Invite members, change roles, remove members | yes | no |
| Rename the organization | yes | no |
An organization always keeps at least one admin. Removing the last one, or demoting them, is refused.
Invites are addressed by email and take the form of a link. An admin creates one for an email address and you share the resulting /join?token=... URL; only an account signed in with that address can open it and join with the role the invite carries — anyone else holding the link cannot use it. Invites expire after seven days and can be used once. Once the invited account signs in, the invite also appears in-app so no link needs to change hands. An account that signs in by phone only has no email and cannot accept an invite.
What belongs to the organization
| Belongs to the organization | Belongs to you as a user |
|---|---|
| The credit balance and every transaction on it | Your SSH keys |
| Instances, and the charges they generate | Your sign-in methods and two-factor |
| Templates the organization owns, private or public | Which organizations you are a member of |
| API keys | |
| The usage log of who did what |
This is the boundary that surprises people. Switching organizations changes the balance you spend, the instances you see, the templates you can edit and the API keys that work. Credits do not transfer between organizations, and there is no way to move an instance from one to another.
Your SSH keys are the exception. They are attached to you, not to an organization, so the same key is selectable at deploy time whichever organization you are working in. Adding a key does not expose it to your teammates, and joining an organization does not give you theirs.
API keys and the boundary
An API key is issued by one organization and is pinned to it. Sending it with a different X-Org-Id is rejected rather than silently redirected.
A key always acts as a member, even when the person who created it is an admin. That means it can deploy, stop and destroy instances, manage templates and read the ledger — and it cannot add credits, invite anyone, mint or revoke other keys, or touch account-level endpoints such as your SSH keys. Admin actions require a signed-in session.
It cannot top the balance up, but it can deploy instances that draw it down. Treat a leaked key as money leaving the account, and revoke it from the API Keys page.