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	✓	✓	✓	✓
Cancel jobs	✓	✓	✓	—
Rerun jobs	✓	✓	✓	—
Trigger manual builds	✓	✓	✓	—
Edit Cloud YAML	✓	—	—	—
Manage environment variables	✓	—	—	—
Configure app settings	✓	—	—	—
Manage schedules	✓	—	—	—
Connect repositories	✓	—	—	—
Configure signing	✓	—	—	—
Manage team members	✓	—	—	—
Share/unshare workspaces	✓	—	—	—
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 is currently identical to MEMBER in terms of permissions. It exists in the system for future expansion and will eventually provide granular administrative capabilities between OWNER and MEMBER.

Reserve this role for team leads or senior developers who may need expanded permissions in the future.

MEMBER

The MEMBER role provides read and execution permissions without configuration access.

Permissions

• View: Workspaces, apps, build history, logs
• Execute: Cancel jobs, rerun jobs
• Download: Build artifacts
• Cannot: Edit configuration, manage team, change settings

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 the workspace
2. Navigate to Settings → Team
3. Click Invite Member
4. Enter the email and select role (ADMIN, MEMBER, or VIEWER)
5. Click Send Invitation

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

Role Selection Tips:

• Choose ADMIN only if planning to grant expanded permissions in the future; currently identical to MEMBER
• Choose MEMBER for developers and build operators
• Choose VIEWER for stakeholders, managers, and read-only access

Removing Team Members

1. Open the workspace
2. Navigate to Settings → Team
3. Find the member in the list
4. Click the Remove button (or three-dot menu)
5. Confirm removal

The member immediately loses access to the workspace.

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 reserved for future expanded permissions (currently same as MEMBER)
  • 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