Skip to main content
Choose how you want GitHub to trigger a deployment:

​
Prerequisites

  • A Rigbox account with GitHub deployments enabled.
  • A repository you can access through the Rigbox GitHub App.
  • An app with installation and start commands, a listening port, and a health endpoint.

​
Connect in the console

  1. Open Settings → GitHub in Rigbox and connect your GitHub account.
  2. Grant the Rigbox GitHub App access to the repository you want to deploy.
  3. Create a workspace and select its GitHub repository, or open an existing workspace’s GitHub deployments settings.
  4. Select the correct GitHub account and repository. Review the branch, project subdirectory, manifest, and deployment strategy. New connections default to incremental; existing connections retain their reviewed choice.
  5. If the repository has a rig.yaml, review the imported app settings. Otherwise, enter the app name, port, install/build/start commands, and memory settings, then review the generated YAML.
  6. Choose automatic GitHub App deployments. If the manifest declares secrets, enter their values under Runtime secrets; see Runtime secrets.
  7. Save the configuration directly or through a pull request. Protected branches require a pull request.
  8. Follow build and deployment progress in the workspace. Open the resulting app URL after the deployment succeeds.
A manifest workspace.deployment.strategy must match the reviewed repository setting. For image strategy, every Git app must declare reproducible: true. Changing strategy requires a fresh review and confirmation; editing YAML alone does not approve replacing the workspace filesystem. The repository’s manifest remains the source of truth. Changes made in Rigbox are saved back to Git; review configuration changes before saving them. See deployment configuration for the manifest fields. Once the connection deploys the workspace’s apps, it owns them, and rig deploy from your machine no longer deploys them. See release ownership.

​
Runtime secrets

A push deploys in Rigbox, not on your machine, so it never reads your shell or .env files. It resolves the manifest’s secrets from the connection’s runtime secrets: values stored encrypted in Rigbox for this connection and never committed to Git. The rig.yaml at the pushed commit decides what each entry looks up:
A value is stored under the entry’s from name, or under its name when there is no from. A required secret without a value fails the push, and the deployment’s status names it. An optional secret without a value is left out: the app deploys without that variable, and the deployment’s status names the optional secrets it went without. Set runtime secrets in either place:
  • Console: open the connection’s configuration and enter NAME=value lines under Runtime secrets, using each secret’s from name. Values you enter replace saved ones; leave the field blank to keep them. Saving redeploys the branch head, unless the save opens a pull request.
  • CLI: run rig deploy in the project directory. For apps the connection deploys, it deploys nothing. It stores the values it resolves from your environment and .env files, for the names that rig.yaml on the connected branch declares, lists the names it stored and any still missing, and exits with an error saying that pushes deploy the apps. The next push deploys with the stored values.
rig deploy stores only secrets that rig.yaml on the connected branch declares. To add a secret, push the rig.yaml that declares it, then store its value. If it is required, that push fails until the value is stored; push again or retry the deployment afterwards. To avoid the failed push, declare it optional: true until its value is stored, or add both in the console, where saving commits the manifest and stores the value together. Check which declared secrets have a value, without showing any values:
Each connection lists every secret declared in rig.yaml on its branch as set, missing, or missing (optional). Stored values are encrypted; once deployed, each is an ordinary environment variable of the app inside the workspace.

​
Deploy through your own CI workflow

Follow GitHub Actions to prepare Git sources, bind an existing workspace with rig ci link, and add the deploy Action. This flow uses short-lived OIDC credentials rather than a saved account API key.

​
Deploy an example

A Deploy to Rigbox button opens a guided flow for choosing a fork, reviewing configuration, and selecting a workspace. That flow creates a deployment branch for its target; push changes to that branch to redeploy it.

​
Troubleshooting

Automatic pull-request preview environments are not yet supported.