Connect GitHub
Select repositories, configure access, and deploy commits automatically.
Openstead uses a GitHub App connection to discover repositories, read the selected revision, and receive deployment events. Connecting GitHub to a workspace is separate from choosing GitHub as your account's sign-in method.
Connect a repository
- Start creating a service and choose a Git repository as its source.
- Connect the GitHub account or organization that owns the repository.
- In GitHub's installation screen, grant the Openstead app access to the repositories you want to deploy.
- Return to Openstead, refresh the repository list if necessary, and select a repository and branch.
- Select the application root when the repository contains more than one application.
Detection reads the repository's manifests and suggests commands. Review those suggestions before deploying, particularly in monorepos and applications with custom entry points.
Change repository access
Use Configure repository access beside the GitHub connection to change the installation's repository selection. For organization-owned repositories, you may need an organization owner to approve the installation or repository access.
If GitHub shows 404 on an installation settings page:
- Confirm you are signed into the GitHub account that can manage that installation.
- Check that the app is still installed and has not been suspended or removed.
- Open the owning account or organization's GitHub App installation settings to locate the current installation.
- Reconnect in Openstead if the original installation was removed and recreated.
Do not assume an old installation URL remains valid after reinstalling the app.
Choose an automatic deployment policy
In the service's settings, set Auto-deploy:
| Policy | Behavior |
|---|---|
| Off | Release manually or through your own automation |
| On every commit | A push to the configured branch can trigger a deployment |
| After CI checks pass | Release the current branch head after GitHub checks and commit statuses report acceptable results |
For the CI policy, a failed or incomplete check prevents the release. Confirm that your workflow actually runs for the configured branch and publishes its results to the same commit. Configure build paths to narrow push-triggered deployments to relevant repository changes.
Private repositories and trusted code
Only repositories visible to the connected installation are available. Keep the installed app's access as narrow as your project allows. Contributors who can change deployed code can execute that code during the build or runtime, so review repository permissions alongside workspace permissions.
Pull-request previews have additional trust rules. In particular, automatic previews do not receive service secrets from forked repositories. See Preview environments.