Adjoint Docs Product ↗
Menu

Users and quotas

How admins invite, manage, and cap developers. For the first invite in a fresh org, see Getting started: admin.

Roles

There are two roles: admin and user (developer). Admins can do everything a developer can (clone, connect, manage their own instances) plus the admin-only surface: cluster provisioning, source connections, imports, catalog sharing/deletion, pools, member management, and quotas. Developers are scoped to their own namespace and their own instances.

Inviting

$ adj invite create [email protected] --ttl 168h
Invite for [email protected] (user) created. Token (shown once):

  9c2f7e51d4a8b3660f1e8d2c5a9b4370c6e1f8a25d3b7c90e4f6a1d82b5c3e70

Send them ONE command:

  adj join adj1.eyJ2IjoxLCJzIjoiaHR0cHM6Ly9hcGkuc3RhZ2RiLmNvbSIsIm8iOiJhY21lIiwidCI6IjljMmY3ZTUxZDRhOGIzNjYwZjFlOGQyYzVhOWI0MzcwYzZlMWY4YTI1ZDNiN2M5MGU0ZjZhMWQ4MmI1YzNlNzAifQ

(legacy form: adj join --server https://api.stagdb.com --org acme 9c2f7e51d4a8b3660f1e8d2c5a9b4370c6e1f8a25d3b7c90e4f6a1d82b5c3e70)

The token is shown once and never stored — forward the adj join adj1.... line as-is; it self-encodes the server URL, org slug, and invite token, so the invitee has nothing else to configure. --ttl accepts 15m–720h (default 72h). --role admin invites another admin instead of a developer.

$ adj invite ls
$ adj invite revoke <invite-id>

adj invite ls shows both pending and already-accepted invites. adj invite revoke invalidates a pending token before it's used — it has no effect on an invite that's already been accepted.

Listing members

$ adj users ls

Shows every member's role and status (active / disabled).

Disable vs. enable

$ adj users disable [email protected]
$ adj users enable [email protected]

disable blocks the member from logging in and revokes their existing sessions — but leaves their instances running untouched. Use this for a temporary hold (someone's off the team for a while, an access review) where you don't want to destroy their databases. enable reverses it.

Remove — the destructive one

$ adj users remove [email protected]
This will remove user [email protected] and destroy their 2 running database(s). Their access is revoked. Proceed? [y/N]: y
Removing [email protected] and reaping 2 database(s) (async).

adj users remove destroys every running instance the member owns. This is the blast-radius operation — unlike disable, there's no undo. The CLI shows you the live instance count before you confirm; skip the prompt with --yes, or block until every one of their databases is actually gone with --wait (--timeout, default 15m). It's safe to re-run: removal is idempotent.

Reach for disable first unless you specifically want their databases destroyed.

Quotas

Two caps, set together or independently:

$ adj quota set --per-user 3 --per-org 30
Quota updated: 3 per user, 30 per org.

--per-user caps how many instances any single member can have running at once; --per-org caps the org total. Omit either flag to leave that cap unchanged.

Anyone can check current usage against the caps:

$ adj quota get
Per-user cap:   3
Org cap:        30
Yours active:   2
Org active:     14

The 429 experience

If a clone would push you over either cap, adj clone fails with an instance-quota error and the CLI prints a hint:

Error: instance quota exceeded: per-user cap 3 reached (HTTP 429)
hint: you've hit your instance quota — destroy one ('adj destroy <id>') or ask an admin

The same check applies whether the clone is served on-demand or fast-claimed from a clone pool — pools make clones faster, not exempt from quota. To get past a 429: destroy something you no longer need (adj destroy <id>), or ask an admin to raise the cap (adj quota set).

Next