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 and start a checkout | 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 links. An admin creates one for an email address, you share the resulting /join?token=... URL, and whoever opens it while signed in joins with the role the invite carries. Invites expire after seven days and can be used once. If the invited address matches the account you are signed in as, the invite also appears in-app so no link needs to change hands.
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, two-factor and passkeys |
| 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.