TempsTemps
On this page
  1. Understand roles
  2. Create a user account
  3. Assign a role
  4. Create an API key
  5. Scope API key permissions
  6. Deployment tokens

Manage Team Access

Temps has three related permission layers: instance account roles, project team roles, and API-key roles/scopes. Keeping those vocabularies separate ensures each teammate and integration receives only the access it needs.

Understand roles

Temps keeps three role layers apart. Instance account roles (Admin, User) apply to every human account across the instance. Project team roles (Owner, Admin, Deployer, Viewer) are granted to teams on specific projects and can only narrow what the instance role allows, and API-key roles (Admin, PlatformAdmin, User, Reader, ApiReader, or Custom with explicit scopes) apply to a single key. Authorization is the reference for what every role and scope permits; this page covers the tasks.

users create --roles <role> and apikeys create --role <role> validate directly against the roles listed above — no dashboard detour needed. Use --roles user or --roles admin for instance accounts, and any of admin, platform_admin, user, reader, api_reader, custom, or metrics_ingest for API keys.

Create a user account

Create a user account

  1. 1

    In the sidebar, click Settings.

  2. 2

    Go to the Users section and click Add User.

  3. 3

    Enter the user's name and email.

  4. 4

    Set a temporary password and keep Require a new password at first sign-in switched on.

  5. 5

    Select the instance role (User or Administrator).

  6. 6

    Optionally pick a team and a team role, then save.

    Checkpoint: The new user appears in Settings > Users and can log in at your Temps instance URL with the provided credentials.

  1. In the sidebar, click Settings
  2. Go to the Users section
  3. Click Add User
  4. Enter the user's name and email
  5. Set a temporary password and keep Require a new password at first sign-in on
  6. Select the instance role (User or Administrator)
  7. Optionally add the user to a team with a team role

The new user can now log in at your Temps instance URL with the provided credentials. Temps does not send invitation emails, so share the sign-in details yourself. Alternatively, let users sign in through your identity provider with OIDC SSO, which creates their account on first login.

Or create the account directly with bunx @temps-sdk/cli users create --username jordan --email jordan@example.com --password '<temporary-password>' --roles user -y. Pass --password: without it the CLI creates an account with no password and sends no invitation, so the user can only get in through OIDC SSO or by using Forgot password? on the login page, which needs an email provider. The CLI does not turn on Require a new password at first sign-in, so ask the user to change the temporary password after logging in.

The first user account is created by the installer, which runs temps setup and prompts for its email and password. It starts with the Admin role. Nobody can change their own roles, but another Admin can remove the Admin role from this account, as from any other.

Assign a role

Assign a role

  1. 1

    Go to Settings > Users and find the user.

  2. 2

    Click Edit (or the actions menu).

  3. 3

    Select the new role and save.

  4. 4

    Role changes take effect immediately on the user's next API call or page load.

    Checkpoint: Confirm the user's Roles column in Settings > Users reflects the new role; active sessions are not terminated.

To change a user's role:

  1. Go to Settings > Users
  2. Find the user
  3. Click Edit (or the actions menu)
  4. Select the new role
  5. Save

Role changes take effect immediately. The user's next API call or page load uses the new permissions. Active sessions are not terminated — the user does not need to log in again.

Permission examples by role

ActionAdminUser
View projects and deploymentsYesYes
Create and deploy projectsYesYes
Manage environment variablesYesYes
View logs and analyticsYesYes
Manage domainsYesYes
Delete projectsYesNo
Manage users and rolesYesNo
Configure backupsYesYes
System settingsYesNo

Create an API key

Create an API key

  1. 1

    Go to Settings > API Keys and click Create API Key.

  2. 2

    Enter a name (e.g. github-actions-deploy or monitoring-readonly).

  3. 3

    Select the permissions to grant.

  4. 4

    Click Create.

  5. 5

    Copy the key immediately and store it securely.

    Checkpoint: The key is shown only once; use it in the Authorization: Bearer header for API calls.

API keys are used for programmatic access — CI/CD pipelines, scripts, monitoring integrations, and MCP servers. For expiry, rotation and how MFA applies to keys, see Authentication → API keys.

  1. Go to Settings > API Keys
  2. Click Create API Key
  3. Enter a name (e.g. github-actions-deploy, monitoring-readonly)
  4. Select the permissions to grant (see below)
  5. Click Create
  6. Copy the key immediately — it is shown only once

The API key is used in the Authorization header:

curl -H "Authorization: Bearer tk_your_api_key" \
  "https://your-temps-instance/api/projects"

Scope API key permissions

Create a scoped CI/CD key

  1. 1

    Go to Settings > API Keys and click Create API Key.

  2. 2

    Name the key for its integration (e.g. ci-deploy or monitoring-readonly).

  3. 3

    Grant only the permissions the integration needs (for CI/CD: deployments:create, deployments:read, projects:read, environments:read).

  4. 4

    Click Create and copy the key, creating a separate key per integration.

    Checkpoint: Confirm the key's permissions match the intended scope so a compromised key can be revoked without affecting other systems.

API keys have no default role: on the Create API Key page you can't continue until you pick a predefined role under Choose Access Level or tick at least one scope under Custom Permissions, and apikeys create needs --role. For least privilege, use Custom Permissions and tick only the scopes the integration needs. A key can never hold a permission its creator lacks. The full list of API-key roles and common scopes is in Authorization.

Common permission scopes:

CI/CD deployment key

Grant only what is needed to trigger deployments:

  • deployments:create — trigger new deployments
  • deployments:read — check deployment status
  • projects:read — list projects
  • environments:read — list environments

Read-only monitoring key

For dashboards and reporting tools:

  • projects:read
  • deployments:read
  • environments:read
  • analytics:read
  • metrics:read

Full management key

For administrative scripts (use sparingly):

  • All permissions — equivalent to Admin role

Security best practice: Create separate API keys for each integration. If a key is compromised, you can revoke it without affecting other systems. Name keys descriptively so you know which integration each key belongs to.

Deployment tokens

In addition to API keys, Temps automatically generates a deployment token for each project environment. This token is injected as the TEMPS_API_TOKEN environment variable in your application container.

Deployment tokens allow your running application to call back into the Temps API — for example, to report analytics events or upload source maps.

These tokens are:

  • Auto-generated by Temps on the first deployment of an environment
  • Scoped to the specific project and environment
  • Reused on every later deployment, not rotated per deploy. The value is set in the container when it is created, so it stays valid across redeploys
  • Not listed under Settings > API Keys. List them with bunx @temps-sdk/cli tokens list --project <project> or GET /api/projects/{project_id}/deployment-tokens (only the token prefix is shown)

You do not need to create deployment tokens manually. They are available in your application as process.env.TEMPS_API_TOKEN. If a token leaks, rotate it with POST /api/projects/{project_id}/deployment-tokens/{token_id}/rotate, then redeploy so running containers pick up the new value.

Last updated

Was this page helpful?