Workspaces and roles

Workspace boundaries

A workspace groups the people and resources that operate together. Servers, projects, instances, GitHub App installation access, subscriptions, and activity records belong to one workspace.

Resources are resolved through the workspace before an operation runs. A member of one workspace cannot use its URL to operate a server or project owned by another workspace.

Choose a workspace slug carefully. It appears in console URLs and should remain recognizable to the team.

Roles

Tnion.SH currently uses three workspace roles:

• Owner: the highest workspace role, assigned to the workspace creator
• Admin: can perform workspace management and operational actions
• Member: can access the workspace and resources available to members without receiving manager privileges

Creating projects, changing servers, provisioning instances, configuring Git sources, making backups, restoring, and similar mutations require a manager role. Keep admin membership limited to people who operate the infrastructure.

Invite a member

From workspace settings, enter the recipient email and choose the intended role. Tnion.SH sends a time-limited invitation link. The invite is scoped to the workspace and records who sent it.

Before sending an admin invitation, confirm the address through another channel. Admins can perform operations that change customer infrastructure and Odoo environments.

If an invitation expires, send a new one. Avoid forwarding an invitation created for one person to another person.

Keep access current

Review workspace membership when a team member changes responsibilities or leaves the organization. Remove access that is no longer required and review recent activity for sensitive changes.

Workspace access is only one layer. Keep VPS provider accounts, domain access, GitHub organization membership, and off-host backup storage current in their own systems as well.