Merge to main. It’s live.
Deploydz runs your self-hosted GitHub Actions runners from the Mac menu bar. Merge to main and the deploy runs on your own Mac, at zero Actions minutes, and the cloud next to your clock shows how it went.
Merge
GitHub Actions does the scheduling. Your Mac does the work, with its own tools and keys.
- You merge to main. GitHub queues the repository’s deploy workflow.
- Your Mac picks it up. The workflow runs on
[self-hosted, deploy], a runner Deploydz keeps running, and uploads the site. - The menu bar shows it. Deploydz reads every deploy’s state and log every 2 seconds, and a notification says when it’s live.
on:
push:
branches: [main]
jobs:
deploy:
runs-on: [self-hosted, deploy]
steps:
- uses: actions/checkout@v4
# feeds the menu bar
- run: |
~/www/actions-runner/deploy.sh \
mysite ./deploy.shYour Mac
It’s the build server now, and Deploydz keeps it running.
- One app runs every runner
- Deploydz starts your runners when you log in, restarts one that stops, and stops them all when it quits. No LaunchAgent per runner.
- Every deploy at a glance
- Each site shows how its last deploy went: when it went live, how long it’s been waiting, or the line it failed on. Its submenu opens the run on GitHub or the deploy’s log.
- App releases too
- Apps that build on your Mac show their version and latest release: the step it’s on, “Released 2 h ago”, or the step that failed.
- Add a runner in one click
- Pick a repository and whether it’s a Website or an App. Deploydz downloads the runner, registers it with
ghand starts it. - Safe with public repositories
- Adding a runner to a public repository makes pull requests from forks wait for your approval, so a stranger’s fork can’t run on your Mac.
- No Actions minutes
- Self-hosted runs are free, and so are releases and their downloads. Nothing runs on GitHub’s machines, so nothing bills.
Setup
- Download the DMG and drag Deploydz to Applications. It’s signed and notarized.
- Open it. The first launch turns on Launch at login, and the cloud appears next to your clock.
- Add a runner. In Settings, + picks one of your repositories and whether it’s a Website or an App.
- Point the workflow at it. A website’s
deploy.ymlruns on[self-hosted, deploy], the Mac job of an app’srelease.ymlon[self-hosted, macOS, release].
What you need
- macOS 15 or later, Apple silicon or Intel
- The GitHub CLI,
gh, signed in - Your repositories on GitHub
- A Mac that’s on when you merge
Help
Does it cost GitHub Actions minutes?
No. Self-hosted runs are free. Keep your Actions budget at $0 in GitHub’s billing settings, so a job that ever lands on GitHub’s own machines fails instead of billing.
Can a pull request from a fork run code on my Mac?
Not without you. When you add a runner to a public repository, Deploydz makes pull requests from forks wait for your approval.
There are no Apps in the menu.
Deploydz asks GitHub about releases with gh, so check that it’s signed in with gh auth status.
A runner shows ○ under Runners.
It stopped, and Deploydz restarts it within 10 seconds. If it keeps stopping, read _diag/deploydz.log in that runner’s folder.
What happens to the runners when I quit?
They stop with Deploydz and start again when it opens. Stop runners in the menu pauses them all without quitting.
How does it update?
Check for updates… downloads the new version and installs it only if it’s signed by the same developer. It waits while a deploy or release is running, because restarting Deploydz stops the runners.
Can a workflow install or update Deploydz?
No. Restarting Deploydz stops every runner, including the one the workflow runs on. Install it by hand, or use Check for updates….
Live
Download Deploydz, add a runner, and your next merge deploys itself.