Loading…

Your code runs on your machines and goes nowhere else.

A job runs in a throwaway VM on a Mac that belongs to someone in your organization, and talks to GitHub directly. HiveWorker decides which machine takes the job. It does not handle the job's code, logs or secrets.

A developer's Mac

Throwaway Linux VM

GitHub's runner, one job, then destroyed

HiveWorker daemon

Runs as your user, not root. No inbound ports.

The Mac's files and keychain stay outside the VM.

GitHub

The job, its logs and its artifacts

HiveWorker coordinator

Presence and job assignment. No job data

One VM per job, destroyed afterwards

Hardware virtualization: Each job runs in its own hardware-virtualized Linux VM. A job cannot read the host's files, keychain or other processes, and it cannot see another job.
Nothing carries over: The VM is created for one job and destroyed when the job ends. The next job starts from a clean image.
GitHub's own runner: Inside the VM is GitHub's official runner, registered with a one-time configuration that is good for a single job.

What the GitHub App can access

The App has no permission for code, repository contents or secrets. It asks for these five permissions and no others.

Permission	Access	What it is for
Self-hosted runnersOrganization	Read and write	Create the hive runner scale sets and register a one-time runner for each job.
MembersOrganization	Read	Check that a person adding a machine belongs to your organization, and to the teams you allow.
ActionsRepository	Read	Receive workflow job events, so a queued job can be matched to a free machine.
MetadataRepository	Read	Required by GitHub for every App.
Email addressesAccount	Read	Sign in with GitHub.

It subscribes to these events: workflow_job, organization, membership, team, installation_repositories. Because the App cannot read contents, a job's checkout happens inside the VM with the token GitHub gives that job.

Who can run your jobs

Your organization's machines only: A private pool contains machines added by members of the GitHub organization that installed the App. Nobody outside it can join, and admins can narrow the pool to specific GitHub teams.
GitHub decides membership: There are no invite codes and no separate user list. When someone is removed from the organization on GitHub, their machines are revoked.
Private repositories by default: The runner labels are created in your organization's default runner group, which GitHub does not offer to public repositories unless you change that.
The public pool comes later: Running jobs on machines outside your organization is not part of the first release. When it arrives it is opt-in per repository and limited to jobs that use no secrets.

The developer stays in control of their Mac

It gives way: When the developer starts using the machine, the daemon throttles the VM and lets the job finish. On battery power or a closed lid, the job is stopped.
It can be paused: The menu bar item pauses the daemon. A paused machine takes no new jobs.
Never root: The daemon runs as a per-user agent with the developer's own privileges. It does not run as root.
No inbound ports: The daemon opens one outbound connection to the coordinator and listens on nothing.

What the coordinator does not see

The coordinator is the HiveWorker service that matches queued jobs to free machines. It is not in a job's data path. The runner inside the VM talks to GitHub directly for the job, its logs and its artifacts.

It does not have: Your source code, build output, job logs, artifacts, caches or secrets. It stores no logs and proxies no job traffic.
It does have: Your organization and its members as GitHub reports them, each machine's hardware details and status, and for each job the repository name, run and job IDs, size, timings and price.

HiveWorker is in early access and has not had an external security audit. To report a problem, write to auth@thecomputerplumbers.com.