---
title: Tokens
description: Credentials for CI, scripts and machines, each carrying a role and pinned where you say.
order: 1
---

A token lets a machine act on ops. It starts with `opst_` and carries the permissions of a
role, taken when the token is made: widening the role later never widens the token, and a
token never carries more than the person who made it holds.

## Making one

| where | for |
| --- | --- |
| `ops login` | the machine you are on, approved by you in the browser |
| **Settings**, **Tokens** in a project | a token pinned to that project, such as for CI |
| your profile, under **Tokens** | a token for any of your memberships |

Give it a name, a kind (API, CLI or MCP), a role and, if you like, the days until it
expires. The token is shown once: copy it then.

A token pinned to a project reaches that project and nothing else. Use pinned tokens for
CI, with the smallest role that does the job: **Deployer** deploys what ops built, and
**Viewer** only reads.

## Using one

Send it as a bearer token, or hand it to the CLI through the environment:

```sh
export OPS_TOKEN=opst_...
export OPS_PROJECT=rungholt
ops deploy web --commit "$COMMIT_SHA"
```

`ops whoami` prints what a token carries: its permissions first, then the memberships of
the person behind it.

## Revoking one

Revoking stops every call with the token at once.

```sh
ops tokens                 # your tokens
ops tokens revoke <id>
ops logout                 # revoke this machine's token and forget it
```

A project admin sees and revokes the project's tokens under **Settings**, **Tokens**.