# How to invite your team to a Runtime account

Open Members, choose Invite member, enter the email address and a role, and send; the link works once, for seven days.

**On Runtime one account holds as many people as you need, with no plan fee,
and they all share its credit, sandboxes and keys.** Each person gets a role,
so a billing contact can add credit without starting sandboxes, and a
developer can run work without touching the bill. Single sign-on and SCIM are
free on every account too, as of 25 September 2026 ([teams](/docs/teams)).

## Send an invitation

1. Sign in as an owner or an admin and open
   [Members](https://withruntime.com/account/members).
2. Choose **Invite member**.
3. Enter the person's email address and pick a role.
4. 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 straight in your
account. Someone who already has a Runtime account keeps it and joins yours as
well; they pick between the two 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 want **Developer**. Give **Admin** to whoever runs the account day
to day, and 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, checked on
every request. Move someone from developer to billing and the keys they made
become read-only at once.

## 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. On the website
they switch from the account name beneath Runtime in the sidebar. From a
terminal, each connected account is saved on the machine:

```bash no-run
npx withruntime account add            # connect the team account; choose it in the browser
npx withruntime account                # list them; * marks the one in use
npx withruntime account switch Acme    # every command after this uses Acme
```

In code, a key belongs to one account, so use a key made in the team account.
`GET /v1/me` names the account and the role behind a key:

```ts check
import { Runtime } from "withruntime";

const runtime = new Runtime();
const me = await runtime.me();
console.log(me.orgName, me.role); // e.g. "Acme" "developer"
```

```python check
from withruntime import Runtime

with Runtime() as runtime:
    me = runtime.me()
    print(me["orgName"], me["role"])
```

## Common mistakes

- **Forwarding the link to a different address.** It only works for the
  address it was sent to. Send a new invitation to the right one.
- **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 ownerless. 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](/how-to/set-up-single-sign-on).

## Remove someone or leave

On Members, open a person's **Actions** menu. **Remove member** takes someone
out; admins remove developers, billing members and other admins, and only an
owner removes an owner. **Leave account** takes you out. Either way access ends
at once, and 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 with who did it and from which address. See
[how to read the audit log](/how-to/read-the-audit-log).

## Related

- [Teams and the audit log](/docs/teams), the full guide
- [Security](/docs/security#read-only-keys-and-daily-limits) for read-only keys
  and daily limits per key
- [Per-user dev environments](/use-cases/per-user-dev-environments) for a
  sandbox for each person on the team

Facts on this page were checked on 25 September 2026.