# How to invite your team to a Runtime account

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

**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](/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**.
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 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:

```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. Use a key made in the team account.
`GET /v1/me` returns 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.** 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](/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](/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 26 October 2026.