Skip to content
runlot

Teams and roles

One organization holds many projects, and each member is assigned one of three roles.

A project always belongs to an organization (org). Your personal organization is created when you first log in, and the organization slug becomes the second label of your deploy URL.

runlot org create acme "Acme Inc."
runlot org list

If you omit name, the slug is used as the organization name.

Roles

RolePermissions
adminEverything: member management, deletion, restore, access control changes
memberDeploys, migrations, secret management, log access
viewerRead operations such as listings, logs, and usage

Commands that are irreversible or that affect data — restores, data deletion, access control changes (pg restore, pg delete, storage delete, auth delete, access set) — can only be run by an admin.

Invitations

All you need is an email address. You can invite someone who has never signed up for runlot.

runlot member invite [email protected] --role member --org acme
runlot member invites --org acme
runlot member uninvite [email protected] --org acme

The dashboard offers the same actions under the organization's Members tab.

The invitation email contains a single acceptance link.

  • The link expires after 7 days.
  • It can be used once.
  • An admin can revoke it at any time, and an email that hasn't gone out yet won't be sent.

Inviting the same address again does not create a second invitation — it re-sends the existing one. A new link is issued, so the previous link stops working. If you change the role when re-sending, the new role applies.

Delivery happens shortly after you invite. If the list shows Sending, the email is still queued.

Whoever holds the link can accept it. The email on the signed-in account does not have to match the invited address, because accounts that keep their GitHub email private must still be able to join an organization. The acceptance screen shows both the invited address and the account you are signed in as, and both are recorded in the audit log. Don't forward invitation links.

If someone who is already a member opens an invitation link, their role does not change. Use member role below to change a role.

Managing members

runlot member ls --org acme
runlot member role [email protected] viewer --org acme
runlot member rm [email protected] --org acme
runlot member leave --org acme

member role and member rm require admin. member leave works for any role — leaving an organization yourself does not change anyone else's permissions.

The last admin in an organization can't be demoted, removed, or leave on their own, because it would leave no one to administer the organization. Trying to do so returns a last_admin error. Promote someone else to admin first.

Removing a member does not stop the projects they created. Those keep running and keep billing. Project ownership and transfer aren't available yet.

runlot org add-member still works, but it identifies people by provider:subject and only accepts accounts that have logged in before — it is meant for automation. Use member invite to bring in a person.

Two-factor authentication

An account can be asked for a six-digit code from an authenticator app on top of its password or social login. Turn it on under Account in the dashboard: scan the QR code with 1Password, Google Authenticator, iOS Passwords or anything else that speaks TOTP, then type one code back to confirm it.

Confirming hands you ten recovery codes, shown once. They are the only way back into the account if the phone is gone, so save them before closing the panel — the server keeps only their hashes and cannot show them again. Each code works once, and enrolling again replaces the whole set.

Turning it off costs a code as well. A signed-in session is deliberately not enough: if it were, somebody who stole a session would simply turn the second factor off first.

Requiring it for everyone in an organization

An admin can require it for the whole organization, under the organization's Settings tab.

While the requirement is on, a member who has not enrolled can still read everything — the list of projects, logs, usage — and every write answers 403 totp_required. That split is deliberate: the banner telling them to enroll is drawn by a screen they have to be able to load, and shutting them out of all of it would leave them with an error page and no instruction.

Turning the requirement on does not sign anybody out. Existing sessions keep working for reads, and the next change they try is what tells them to enroll.

How the target organization is chosen

The CLI picks the target organization in this order.

  1. The --org option
  2. The "org" value in runlot.json
  3. An error if neither is present

Commands that operate at the organization level, such as org, dns, and domains, run independently of your project directory, so you have to pass the --org option.

On this page