Deploy from GitHub. Connect a repository and deploy every push.

Hub deploys from GitHub through the Hub GitHub App. Once you connect an app, every push to its branch deploys it, whatever your local folder holds.

From a clone

Run hub deploy inside a git repository whose branch has a remote on GitHub. Hub connects the app to that repository, branch and subfolder, deploys the branch head, and keeps deploying new commits:

Live at https://crm.acme.myhub.host
Auto-deploy: every push to main

The first time, Hub needs access to the repository. The CLI prints Hub needs access to owner/name on GitHub and opens GitHub in your browser. Approve the app for the repository, and the CLI carries on once GitHub sends you back. Your browser needs to be signed in to Hub as you.

If the folder has changes GitHub does not have yet, the CLI asks what to deploy: the last pushed commit and every push after it, or the files as they are now, uploaded once. Scripts answer with a flag:

hub deploy --pushed   # the last pushed commit, then every push
hub deploy --local    # upload the folder as it is, skip GitHub

A remote that is not on GitHub, or a detached HEAD, deploys as an upload.

Without a clone

hub deploy --git owner/repository
hub deploy --git owner/repository --branch main --path apps/admin --name admin

--git uses the repository's default branch unless you pass --branch, and its root unless you pass --path. --no-watch connects without deploying on push.

Change the source

hub app admin git                   # the repository, branch, path and last commit
hub app admin git --watch off       # stop deploying on push
hub app admin git --branch release  # switch branch and deploy its head
hub app admin git --disconnect      # stop following GitHub, keep the running release

hub app admin redeploy deploys the branch head again, with auto-deploy on or off.

How pushes arrive

GitHub tells Hub about each push, and Hub also checks every watched branch every 10 minutes, so a missed notice costs 10 minutes at most. An instance runs one deploy at a time; a newer commit replaces one still waiting. A commit whose deploy failed is not tried again until a new commit arrives or you redeploy.

Hub fetches the one commit it deploys. Submodules and Git LFS files are not fetched.

When a deploy fails

When a deploy from GitHub fails to build or start, Hub reads the failure and may open a pull request on the repository with a proposed fix. The build log ends with the pull request link. Nobody reviews the change before Hub opens the pull request, so read it before you merge.

Hub makes at most one attempt per commit, and at most 5 a day per org. Failures no change to the repository would fix, such as a full disk or a rate limit, get no attempt. Opening pull requests needs the Contents and Pull requests permissions on the Hub GitHub App; GitHub asks an admin of your account to accept them.