Roles & Permissions

Overview

RunnerHub uses a role-based access control (RBAC) system for managing team members and their permissions. Four roles define what team members can do within a workspace, from full administrative control down to read-only access.

Role Matrix

Permission	OWNER	ADMIN	MEMBER	VIEWER
View workspaces	✓	✓	✓	✓
View apps & jobs	✓	✓	✓	✓
View logs & artifacts	✓	✓	✓	✓
Download artifacts	✓	✓	✓	✓
Trigger builds (cancel/rerun)	✓	✓	✓	—
Manage app settings	✓	✓	✓	—
Delete apps	✓	✓	—	—
Edit Cloud YAML	✓	✓	—	—
Manage environment variables	✓	✓	—	—
Manage schedules	✓	✓	—	—
Connect repositories	✓	✓	—	—
Configure signing	✓	✓	—	—
Manage secrets	✓	✓	—	—
Manage team members	✓	✓	—	—
Delete workspace	✓	—	—	—
Manage billing	✓	—	—	—

OWNER

The workspace owner has full administrative control over the workspace and all its resources.

Responsibilities

• Create and delete apps
• Configure build pipelines (Cloud YAML)
• Manage environment variables
• Set up Apple code signing credentials
• Create and manage team members
• Share workspaces with team members
• Manage billing and subscription
• Access all job logs and artifacts

Billing Responsibility

The workspace OWNER is responsible for the subscription plan and billing. All minutes used by team members (including reruns) are charged to the OWNER’s account.

Note

If multiple users in an organization need full control, consider creating multiple workspaces or requesting administrative team features (coming in future releases).

ADMIN

The ADMIN role provides management capabilities for team configuration and app lifecycle, while maintaining developer execution permissions.

Responsibilities

• Manage team members (invite, remove, change roles)
• Configure app settings (environment variables, signing, schedules, repositories)
• Create and delete apps
• Trigger builds (cancel, rerun)
• View all team resources

Use Cases

• Team leads who need to configure settings and manage team access
• Senior developers who manage app configurations
• DevOps engineers responsible for CI/CD setup

MEMBER

The MEMBER role provides build execution and monitoring without configuration management.

Permissions

• View: Workspaces, apps, build history, logs
• Execute: Trigger builds (cancel, rerun)
• Download: Build artifacts
• Cannot: Edit configuration, manage team, manage apps, manage signing

Use Cases

• Developers who need to monitor builds and rerun jobs
• QA engineers who need to download artifacts
• Team members who should not modify CI configuration
• Contractors or freelancers with limited scope

Member Visibility

The UI adapts to member permissions:

• Configuration tabs (Cloud YAML, Variables, Settings, Schedule, Repositories) are hidden for MEMBER users
• Direct URL navigation to restricted pages redirects to the Jobs tab
• Only executable actions appear in the interface

Caution

Members cannot accidentally modify configuration because those UI elements are not shown.

VIEWER

The VIEWER role provides read-only access to a workspace. Viewers can see all builds and artifacts but cannot execute any actions.

Permissions

• View: Workspaces, apps, build history, logs, and artifacts
• Download: Build artifacts
• Cannot: Cancel jobs, rerun jobs, trigger builds, edit any configuration

Use Cases

• Stakeholders or managers who need to monitor progress
• Clients who need visibility into builds without execution rights
• Team members from non-technical departments
• Archival/read-only team access during project transitions
• Compliance officers or auditors who need visibility

Viewer Visibility

The UI adapts to viewer permissions:

• All build and artifact viewing features are available
• Configuration tabs (Cloud YAML, Variables, Settings, Schedule, Repositories) are hidden
• Action buttons (Cancel, Rerun, Trigger Build) are disabled or hidden
• Direct URL navigation to restricted pages redirects to the Jobs tab

Note

VIEWER role is useful for read-only monitoring without any risk of accidentally modifying builds or configuration.

Billing & Free Users

Charging Model

• Minutes are charged to the workspace OWNER, regardless of who triggered the job
• If a MEMBER reruns a job, the cost is charged to the OWNER
• Teams do not require PAYG or higher plans for each individual member

Free Users as Team Members

• A user on the Free plan can be invited as a MEMBER to teams owned by paid users (PAYG, Pro, Business)
• Free members consume minutes from the team owner’s plan
• Free users themselves cannot create teams (only PAYG+ users can create teams)

Tip

This is useful for onboarding new team members without requiring them to purchase their own subscription. Once they’re familiar with the platform, they can upgrade if they need to create their own workspaces.

Adding Team Members

Only OWNER can invite new team members.

1. Open your workspace
2. Navigate to Teams → [team card]
3. Click the Add icon button (person_add)
4. Enter the email and select role (ADMIN, MEMBER, or VIEWER)
5. Click Send Invite

The invited user will receive an email invitation. They can accept the invitation to gain access to the team.

Role Selection Tips:

• Choose ADMIN for team leads and those who need to manage app settings and team members
• Choose MEMBER for developers and build operators
• Choose VIEWER for stakeholders, managers, and read-only access

Removing Team Members

1. Open your workspace
2. Navigate to Teams → [team card]
3. Find the member in the list
4. Click the Remove button or icon
5. Confirm removal

The member immediately loses access to the team and shared workspaces.

Permission Scenarios

Scenario 1: Indie Developer with Contractors

• OWNER: Indie developer
• MEMBERS: Contractors who need to monitor builds and download releases

Scenario 2: Small Team

• OWNER: Engineering lead (manages billing, configuration)
• MEMBERS: 2-3 developers (run jobs, view logs)

Scenario 3: Enterprise Team

• OWNER: Tech lead (overall responsibility)
• ADMIN (future): DevOps engineer (expanded permissions)
• MEMBERS: Developers (daily CI usage)
• VIEWER: Product managers, stakeholders (monitoring only)

Scenario 4: Multi-Department Access

• OWNER: Engineering lead
• MEMBERS: Backend and iOS developers
• VIEWER: QA team, product managers, client stakeholders
• Result: Everyone can see builds, only developers can execute

Best Practices

Permission Assignment

Tip

• Principle of Least Privilege: Assign the minimum role needed
  • VIEWER for read-only stakeholders
  • MEMBER for developers and build operators
  • ADMIN for team leads and configuration managers
  • OWNER only for those responsible for configuration and billing
• Clearly communicate roles: Make sure team members understand what they can and cannot do
• Rotate ownership: In critical projects, ensure multiple people have owner access (via separate workspaces)
• Monitor team growth: Review team composition quarterly to ensure proper access levels
• Onboard with VIEWER: Start external stakeholders as VIEWER; promote to MEMBER if they need to execute builds

Role Transitions

When a team member’s responsibilities change:

From	To	Notes
VIEWER → MEMBER	Person now needs to rerun/cancel builds	Increase privileges
MEMBER → VIEWER	Person moving to non-technical role	Decrease privileges
MEMBER → OWNER	Rare; consider creating separate workspace instead	High responsibility

External Access

• Contractors: Usually MEMBER; use VIEWER if they only need to monitor
• Clients/Stakeholders: Use VIEWER for maximum safety
• Vendors: VIEWER only, never OWNER
• Auditors: VIEWER to maintain read-only compliance