Access Control
Access control in Tapitalee centers around team memberships. Users can belong to one or more teams, and roles are assigned per-team. This page explains how roles, permissions, and tokens work together to control access.
Team Memberships
Everything in Tapitalee is organized around teams. Users can belong to multiple teams, with each membership having its own assigned role. This allows users to have different permission levels across different teams.
Each role provides a specific set of permissions:
| Role Permissions | Read-only | Member | Admin | Owner |
|---|---|---|---|---|
| View all (excluding secret variables) | ✓ | ✓ | ✓ | ✓ |
| Deploy apps | ✓ | ✓ | ✓ | |
| Manage variables | ✓ | ✓ | ✓ | |
| Create and run tasks | ✓ | ✓ | ✓ | |
| Create releases | ✓ | ✓ | ✓ | |
| Modify apps, processes, add-ons, domains, and commands | ✓ | ✓ | ||
| Approve releases | ✓ | ✓ | ||
| Manage team memberships and access rights | ✓ | |||
| Delete team | ✓ |
Access Rights (Enterprise Plans)
On enterprise plans, lower-privileged users can be granted additional permissions via Access Rights. These can be assigned on either:
- Per-team basis: Grant additional permissions to all apps within the team
- Per-app basis: Grant additional permissions to a specific app only
This allows fine-grained control, such as allowing a read-only user to deploy a specific application without giving them deployment rights across the entire team.
Tokens
Tapitalee has four types of tokens, each scoped for a different purpose:
| Token Type | Description | Location |
|---|---|---|
| CLI Token | Full CLI access to your user account, across all your teams. | $HOME/.tapitalee/config.toml, written after a successful tapit login. |
| Deploy Token | Scoped access to a single app, for use in GitHub Actions and other CI/CD pipelines. | Deploy Tokens submenu in App settings. |
| API Token | Attached to a user, granting access to all apps in one team based on that membership’s role. | Edit Member in Team Members. |
| Agent Account | A virtual user for agents and scripts, with CLI-only access. Use it to obtain API tokens for automation. | Agent Accounts in the main menu. |
Agent Accounts
An Agent Account is a virtual user designed for agents and scripts rather than a person. It has CLI-only access and exists to provide API tokens for automated, non-interactive use.
Agent Accounts:
- Represent automation rather than a real person
- Have CLI-only access (no interactive dashboard login)
- Provide API tokens for agents and scripts
- Can be managed and revoked from Agent Accounts in the main menu
Access Report
Team owners and admins have a Access Report page in the main menu, alongside the Cost Report. It reviews the whole team at once, rather than one app at a time, and has three sections:
- Who has access to what: every team member and agent account, their role, whether the access applies to all apps or one app, the individual access rights granted, and how many unexpired API tokens they hold.
- What is open to the internet: every process and add-on that is reachable from outside its own app, what it is open to (the entire internet, all apps in the same VPC, or specific IP ranges), and an explanation including the ports involved. Publicly readable S3 buckets, CloudFront distributions, public container registries, internet-facing load balancers, reverse proxies and public DNS names are listed too.
- Add-ons shared with other apps: each shared add-on, the app that owns it, the app it is shared with, whether the share is read-only or full access, and the name of the secret injected into the target app.