For developers
Publish from GitHub
Connect a repository once, and every push to the branch you chose republishes the site. No build runs on our side — we take the files as they are in the repo.
Connecting
Your site → GitHub → install the Lemonade Host app on the repository you want. GitHub asks you to pick which repositories it may read; pick the one. When you come back, you choose:
- the branch —
mainunless you say otherwise; - the folder inside the repo to publish — leave it empty to publish the repository root;
- automatic publishing — on by default. Turn it off and the connection stays, but pushes stop publishing until you press Deploy now.
What we can see
Read access to the one repository you chose, and nothing else. The GitHub app asks for contents (read), metadata (read), and the push event. It never writes to your repository, and it has no access to issues, actions, packages or your organisation's members.
There is no build step
We fetch the repository's files and serve them. If your project needs npm run build to produce the site, run that build wherever you already run it and commit or publish the output — or point the folder setting at a directory that is already built.
A repo whose root is source code rather than a built site publishes successfully and serves your source. That is the most common surprise, and it looks like "GitHub deploys are broken" when it is not.
When a push does not publish
The site's GitHub tab shows the reason for the last push that failed, in plain words. The usual ones:
- the files failed one of the publish checks — a file over 25 MB, or
node_modulescommitted; - the branch you chose no longer exists, or was renamed;
- the app was uninstalled or lost access to the repository on GitHub's side.
A failed publish changes nothing. The version that was live stays live.
Published, but not live
A site that has not been paid for, or is waiting on our review, accepts a publish and serves none of it. The GitHub tab says so rather than reporting a green deploy over a site nobody can see. Publish the site once from the portal and it goes live.
It mixes with everything else
A connected site can still be published from the CLI, the API or a drag-and-drop zip. The last publish wins, whichever door it came through, and the site's Activity names the door each time.