# Deploy from GitHub | answer.cloud Docs

> Canonical source: [Deploy from GitHub | answer.cloud Docs](https://www.answer.cloud/docs/hosting/github/)

Connect GitHub for push-to-deploy, select Actions or prebuilt output mode, and automatically save successful uploads to the linked branch.

guide

# Deploy from GitHub

Connect GitHub for push-to-deploy, select Actions or prebuilt output mode, and automatically save successful uploads to the linked branch.

Reviewed November 1, 2026

GitHub push-to-deploy connects one repository to one Answer Cloud site. The site's plan must include GitHub integration, and your GitHub account must grant the Answer Cloud app access to the intended repository.

## 1. Connect the repository account

Ask your agent to call `github_get_connection` for the selected organization. If the connection is absent, open the returned `install_url` in your browser and authorize the GitHub account and repositories you want to expose. Then have the agent inspect the connection again.

Choose the repository deliberately. Granting the app access and linking the repository are separate steps; neither substitutes for verifying the selected Answer Cloud site.

## 2. Select the build mode

| Mode      | Repository contents           | Deployment behavior                                         |
|-----------|------------------------------|-------------------------------------------------------------|
| `actions` | Editable Astro or other build source | GitHub Actions builds the site and uploads the output using OIDC |
| `none`    | Already compiled static output | Answer Cloud deploys the linked branch directly without a build job |

Use `actions` for a normal Astro project. Link with `github_link_repo`, supplying `site_slug`, repository as `owner/name`, branch, and any source/output directories. The default branch is taken from the repository when none is specified. One repository cannot power several linked sites.

A source subdirectory and output directory are distinct settings: a monorepo might build within `website/` and publish its `dist/` output. Verify the returned configuration instead of assuming the repository root is the artifact.

[![GitHub panel showing Push-to-deploy is on, direct deployment from main, and Deploy branch head now.](https://www.answer.cloud/assets/docs/github-static-deploy.jpg)](https://www.answer.cloud/assets/docs/github-static-deploy.jpg)

For prebuilt static output (`none`), the dashboard shows direct push-to-deploy controls.

## 3. Install the generated workflow

For Actions mode, write the returned workflow to `.github/workflows/answercloud.yml`, review it, and commit and push through your normal repository process. The generated workflow uses `id-token: write` and `contents: read` for short-lived OIDC deployment access, so no long-lived deployment secret needs to be copied into GitHub.

If the workflow cannot be committed because GitHub returns a permission error, inspect the app or token's workflow-write permission. Contents access alone may not permit changing `.github/workflows/`.

With the release workflow active, automated uploads default to staging. Confirm the release configuration before pushing a change you expect to reach production. Use [promotion](https://www.answer.cloud/docs/hosting/environments/) after review when appropriate.

## Automatic commits after uploads

With GitHub enabled and a repository linked, successful uploads through `start_deploy` / `finalize_deploy` or `deploy_files` also save public deployed files to the linked branch. This applies to staging, production, and deployments targeting both. Saving runs after publication, so the site can be live before its commit appears.

For `build: none`, files are saved under `dir`; for `actions`, under `output_dir` beneath `dir`. The commit contains deployed output, including generated public files. Preserve the editable source project separately from that output. Private CMS templates and GitHub workflow files are excluded.

Changed output files are updated, obsolete files tracked by the preceding save are removed, and unrelated repository files are preserved. Unchanged output reuses the existing commit. GitHub-originated deployments already have a commit and are not saved again. Automatic saves skip Actions builds and their own push webhook, so they do not create another deployment.

Deploy history and the `git` result from `get_deploy` and `list_deploys` show the completed commit. Filter `list_deploys` with its full `commit_sha` to find a deployment by the saved commit. Temporary GitHub errors retry automatically. If saving ultimately fails, the site stays live and receives `github_commit_failed`. Check the GitHub connection and repository access, then deploy again.

## 4. Verify the actual commit

After the push, inspect the Actions run for Actions mode, then use `list_deploys` and `get_deploy`. Compare the deployment's `git` metadata with the commit you intended and verify the public result.

For `build: none`, the GitHub commit check is named `answer.cloud`; for Actions mode, inspect the Actions job status.

For `build: none`, `github_trigger_deploy` can deploy the linked branch head without another push. It does not build Actions sites; rerun their GitHub workflow instead.

`github_unlink_repo` stops push-to-deploy and automatic deployment commits while preserving the current live site. Manual deployment remains available. See the [GitHub tool reference](https://www.answer.cloud/docs/reference/github-tools/) for arguments and errors.