Automate publication of the home branch instead of hand-deploying the landing page

[allister-beamable]

help.beamable.com/ redirects to gh-pages:Home/, which is built from the home branch. It is the site's front door: the product chooser with the Unity, Unreal, Web SDK, CLI, and API cards, and the only thing that makes a product line discoverable to a reader who starts at the top.

Expected: pushing to home publishes it, the way pushing to any other published branch does.

Actual: nothing happens. home has no auto-publish-branch.yml, so every publish is a hand-run mike deploy Home --push from someone's laptop. Every Deployed … to Home commit on gh-pages is authored vitor@beamable.com at UTC-3 with mkdocs 1.6.1 / mike 2.1.3 — compare Unity-6.0, whose deploys are authored by github.com service accounts at +0000.

Why this is a bus factor rather than a cosmetic gap

• One person has ever deployed it, and docs bandwidth is currently thin
• Until mkdocs-open-in-new-tab was pinned on main (2026-07-31) the branch could not even be built from a setup.sh environment: home's mkdocs.yml declares the open-in-new-tab plugin, which was not in requirements.txt, and a missing plugin is a configuration error rather than a warning. So the landing page was effectively un-editable by anyone else
• home carried no .github directory at all until the anti-BOM check was added, so there was no trace on the branch of how it ships
• Because deploy-branch.yml is read from the selected branch's tree, Deploy Docs Branch cannot even be dispatched against home. There is no manual GitHub-side path either — only a local clone

The fix looks small

internal is the precedent: a versionless branch, handled by a special case in its own copy of the workflow.

if [ "${BRANCH,,}" = "internal" ]; then
  PRODUCT_NAME="Internal"
  VERSION="Latest"
  MIKE_ALIAS="Internal"
else
  # ... derive product from the branch prefix, version from the suffix
fi

home needs the same shape with a fixed Home alias, plus - 'home' in on.push.branches. The prefix/suffix derivation cannot work for it — home has no / and no version component.

Two things that make this easier than it looks:

• No manual first publish needed. Auto-publish greps mike list and skips the deploy entirely if the alias is unknown. Home is already in versions.json, so the guard passes on the first push
• home is tiny — three Markdown files, one real page. The build is well under a second

Include the concurrency group

internal's copy of the workflow is missing the

concurrency:
  group: gh-pages-deploy
  cancel-in-progress: false

block that toolkit/v0.4's copy has. Whatever lands on home should include it, since an unguarded deploy competes for the same gh-pages slot — see #66.

Closely related, same shape, not the same branch

websdk/v1.0 is published as WebSDK-1.0 and also has no auto-publish-branch.yml, so it is hand-deployed too. Other branches' copies list websdk/** in on.push.branches, which reads as covered but is not: triggers come from the pushed branch's own tree, so a push to websdk/v1.0 fires nothing. Worth fixing in the same pass; unlike home it needs no special case, since the prefix/suffix derivation already handles it.