On Runtime, one account holds as many people as you need, with no plan fee. All of them share its credit, sandboxes and keys. Each person gets a role. A billing contact can add credit without starting sandboxes. A developer can run work without changing the bill. Single sign-on and SCIM are free on every account too, as of 26 October 2026 (teams).
Send an invitation
- Sign in as an owner or an admin, and open Members.
- Choose Invite.
- Enter the person's email address, and pick a role.
- Choose Send invitation.
The person gets an email with a link. The Members page shows the same link, so you can paste it into your team chat instead of waiting for the email.
Someone new to Runtime signs up through the link and lands directly in your account. Someone who already has a Runtime account keeps it and joins yours as well. They choose between the two accounts later.
Pick the right role
| Role | Runs sandboxes | Makes keys | Adds credit | Invites and removes | Reads the audit log |
|---|---|---|---|---|---|
| Owner | yes | yes | yes | yes, owners too | yes |
| Admin | yes | yes | yes | yes, not owners | yes |
| Developer | yes | yes | — | — | — |
| Billing | — | — | yes | — | — |
Every role can see resources, usage, the balance, keys and members. Most engineers need the Developer role. Give Admin to whoever runs the account day to day. Keep Owner for the few people who may hand the account over.
A key never does more than the role of the person who made it. Runtime checks this on every request. Move someone from developer to billing, and the keys they made become read-only immediately.
Invitation rules
| Rule | Value |
|---|---|
| How long a link works | Seven days, and only once |
| Who can use it | Only someone who signs in with that email address |
| Open invitations per account | 50 |
| Invitations sent per day | 25 in any 24 hours |
| Sending again | Replaces the earlier invitation to the same address |
| Cancelling | Withdraw on the Members page |
Work in more than one account
A person can belong to their own account and their company's account. On the website, they switch accounts from the account name at the top of the sidebar. From a terminal, each connected account is saved on the machine:
Terminalnpx withruntime account add # connect the team account; choose it in the browsernpx withruntime account # list them; * marks the one in usenpx withruntime account switch Acme # every command after this uses AcmeIn code, a key belongs to one account. Use a key made in the team account.
GET /v1/me returns the account and the role behind a key:
TypeScriptimport { Runtime } from "withruntime";const runtime = new Runtime();const me = await runtime.me();console.log(me.orgName, me.role); // e.g. "Acme" "developer"Pythonfrom withruntime import Runtimewith Runtime() as runtime: me = runtime.me() print(me["orgName"], me["role"])Common mistakes
- Forwarding the link to a different address. The link works only for the address it was sent to. Send a new invitation to the right address.
- Inviting a work address for someone who signs in with Google on a personal one. They must sign in with the invited address. Invite the address they use.
- Trying to leave as the last owner. Runtime refuses, so an account is never without an owner. Make someone else an owner first, then leave or change your own role. This is also how you hand an account over.
- Removing someone and expecting their sandboxes to go. What they created, such as sandboxes, volumes and images, stays with the account. Their access and every key they made end in the same step.
- Inviting a large team by hand. With your company's identity provider, people join on first sign-in with the role you choose. See how to set up single sign-on.
Remove someone or leave
On Members, choose Remove at the end of a person's row, and confirm. Admins remove developers, billing members and other admins. Only an owner removes an owner. Leave, on your own row, takes you out. Either way, access ends immediately. The person can be invited back later with a new role.
Every invitation sent and withdrawn, every join and every role change is in the audit log. The log records who did it and from which address. See how to read the audit log.
Related
- Teams and the audit log, the full guide
- Security for read-only keys and daily limits per key
- Per-user dev environments for a sandbox for each person on the team
Facts on this page were checked on 26 October 2026.