Skip to main content
Everything in Tesser belongs to an org. An org can be just you, or several people; either way the boxes, the shared instances, and the service names all live in it together. An account can belong to more than one org, and tesser login asks which one to use when it matters.

​
Orgs on this laptop

Setting TESSER_ORG=<id> for a command uses that org for that command only. tesser whoami prints the signed-in email and the current org.

​
Adding a teammate

An admin runs:
They are a member from that moment. That address gets an email from noreply@tesser.sh naming the org, with a link to the dashboard and the install line. The next time that person runs tesser login, the browser offers them the org; signing in on the dashboard lands them in it. Running add again resends the email. The Organization tab on the dashboard does the same thing through a form. There are two roles, admin and member. Admins manage members, service env values, and the warm pool, and they can operate on any box in the org. Members create and use their own boxes, wake and keep the shared instances, and pin them to a commit with --ensure-running. The last remaining admin cannot be demoted or removed.

​
Seeing each other’s boxes

tesser ls lists every box in the org, including teammates’ boxes, and tesser status shows who owns a given box. A box carries the keys of its owner’s laptops and of the org admins, nobody else’s. To let a teammate look at one, its owner runs tesser share <box_id> and sends the link. The teammate opens it (or runs tesser review <link>), the control plane puts their key on the box and on the boxes of yours it depends on (never on the org’s shared instances), and it appears at <box_id>.localhost:<port> on their laptop, with tesser ssh for a shell. They see the box as it is, uncommitted changes included, and they count as another owner of it while the link lives: sync, dev, wire, sleep, and rm all work, so a sync from their worktree overwrites the author’s. Links expire, die with the box, and can be revoked; each of those takes the key and the access back. This is how a pull request gets reviewed against the author’s running box. An org running in its own AWS account can also run a share gateway: then tesser share prints https://box-<id>.<host>:<port> URLs as well, which anyone on the company network opens in a browser, no tesser install or login needed, for as long as the link lives. What a team shares without any link are the shared instances, such as one api at main that everyone’s boxes connect to. See Connect a frontend to a backend.

​
Tokens

A laptop signs in through the browser. A machine without a browser uses a token created on the dashboard under Settings, CLI tokens, or one an admin mints for a service account with tesser member token create:
You can also save such a token once with tesser login --token tsr_api_… --org org_…. Tokens belong to one org, so a token created in org A is not valid in org B, and every token expires (90 days from the dashboard; whatever --expires said). tesser logout revokes the saved token and deletes it from disk.

​
Agents and CI

An agent platform or a CI job that can prove who it is with an OpenID Connect id token needs no stored secret. A grant is a rule: id tokens from one issuer whose claims match the grant’s pins may be exchanged for a tesser token acting as one service account. Grants are org-level, admins make them, and they are always for a service account, never for a person. The grant’s id is not a secret and can be committed.
Each prints the id and the tesser login oidc --org org_… --grant grt_… line to run where the issuer is. The CLI gets an id token with the control URL as its audience, the control plane checks it against the issuer’s keys and the pins, and hands back a token that lasts as long as the id token, an hour at most; the CLI proves again when that token is about to expire. An SSH key added with that token is dropped from every box once the last token of its session (a GitHub run, a Devin session) expires or is revoked. Inside a GitHub Actions job with permissions: id-token: write the CLI mints the id token itself:
For Devin and Replicas the printed line carries --proof '<command>', a command that prints the id token. Boxes an agent session makes show as devin · <session> and are recorded as made for the person who started the session: their email from the id token, or an alias an admin set with tesser member alias set (Actions carries no email, so its actor_id only ever attributes through an alias). They show in that person’s dropdown. tesser grant rm stops new exchanges. A person who wants an agent to act as themselves does not need a grant: they paste their own token into it, tesser login --token tsr_api_… or TESSER_TOKEN, minted on the dashboard. Usage is metered per box-second and shown on the dashboard’s Usage tab.