Team and access

Roles

What Owner, Admin, Operator and Viewer can each do — the complete table.

Four roles. Every request is checked against them on the server, so a role is a real boundary, not a hidden menu.

Role	Typical person	In one line
Owner	Whoever pays	Everything, including billing and deleting the team. One per team
Admin	The CTO or co-founder	Everything except billing and deleting the team. Can manage members
Operator	The hired DevOps engineer	Works on servers: terminal, files, restarts, chat in Execute mode. Cannot add, edit or delete platform resources, and cannot delete cloud resources
Viewer	A junior, an auditor, a PM	Sees everything, changes nothing. No terminal, no file manager, no secrets

The three rules behind the table

Platform resources — projects, servers, stored credentials, integrations, members — are added, edited and deleted by Owner and Admin only.
Cloud resources — EC2, S3, CloudFormation — can be created and changed by an Operator, but never deleted or terminated.
Inside a server, an Operator can do whatever that server's SSH login can do. A Viewer gets the read-only tabs.

The full table

✅ allowed · — refused by the server

Area	Action	Owner	Admin	Operator	Viewer
Team	Add/remove members, change roles, reset passwords, disable	✅	✅	—	—
Team	Billing, Account ID, delete the team	✅	—	—	—
Projects	Add, edit, delete; colour labels	✅	✅	—	—
Servers	Add, edit, delete; save or unlock a key or password	✅	✅	—	—
Servers	See the list, health, "check now", Activity log	✅	✅	✅	✅
Servers	Open a server; Monitor, Logs, Services, Docker, PM2, Nginx, Packages, Scheduled, Users	✅	✅	✅	✅
Servers	Restart services, containers and apps; edit nginx; install packages; edit cron; manage Linux users; kill processes; truncate logs	✅	✅	✅	—
Servers	Terminal, and the terminal's AI helper in Execute	✅	✅	✅	—
Servers	File manager; read any file via Logs; see environment variables	✅	✅	✅	—
Chat	Chat and tasks in Read mode, attach servers to your own chats	✅	✅	✅	✅
Chat	Execute mode, auto-approve, answering approval cards	✅	✅	✅	—
Chat	Reads that return secrets (`.env`, keys, Secrets Manager…)	✅	✅	✅	—
Cloud	View EC2, S3 (including downloads), IAM, CloudWatch, Cost, CloudFormation, GuardDuty, Inspector	✅	✅	✅	✅
Cloud	Create or change: S3 upload, new folder, new bucket; CloudFormation create and execute	✅	✅	✅	—
Cloud	Delete or terminate anything in the cloud	✅	✅	—	—
Integrations	Add, edit, remove Jenkins, Jira, Grafana, MCP, MySQL, log sources, AI models	✅	✅	—	—
Integrations	Use them: Jenkins audit, Jira edits, saved dashboards, MCP tools that change things	✅	✅	✅	—
Integrations	Read them: Jenkins jobs, Jira boards, Grafana dashboards, read-only MCP tools	✅	✅	✅	✅
Uptime	View monitors, checks, response times	✅	✅	✅	✅
Uptime	Pause, resume, check now	✅	✅	✅	—
Uptime	Create, edit, delete monitors	✅	✅	—	—
Personal	Own notes, own chats, own password, own default AI model	✅	✅	✅	✅
AI credit	Spends the team's pooled credit	✅	✅	✅	✅

Choosing a role

An engineer who will do the work → Operator. They can fix things and cannot delete your infrastructure or your stored credentials.
A co-founder or second admin → Admin.
A client, an auditor, a project manager, a junior learning → Viewer.
You → Owner. There is one per team.

Two honest caveats

Operator's real limit on a server is the SSH login you configured. If that login is root, an Operator has root on the machine, because that is what the server grants. The role controls what DevOps Agent will do for them, not what Linux permits.
A Viewer's "no secrets" rule in chat is a deny list, not a proof. It blocks the known ways of reading secrets. Treat it as a strong guardrail rather than a guarantee — if someone must never see a secret, do not give them a login to a system that can reach it.

Restricting to some projects

When adding or editing a member you can limit them to specific projects. An agency uses this to give each engineer only their own clients. See Add a member.