GitHub
Connect a GitHub repository to a project to authenticate your Actions deploys and keep platform branches in sync with your Git branches.
Connecting a GitHub repository wires a project to your repo. Deploys run in your own GitHub Actions, through prisma/cloud-deploy-action; the connection provides two things around them:
- Credentials. Workflow runs in the connected repository exchange their GitHub OIDC token for a short-lived Prisma workspace token, so the deploy workflow needs no secrets.
- Branch lifecycle. Branch events keep the matching platform branches in sync, including tearing a preview down when its Git branch is deleted.
For the full setup, from connection to a live preview per branch, follow Deploy on push.
How it works
The connection has two levels:
The workspace owns the GitHub App installation; each project points at a single repository. Once connected, Prisma verifies the repository identity behind each credential exchange and listens for the repo's branch events.
Connect a repo
You can connect through the Console or from the CLI. The Console also opens a pull request that adds the deploy workflow to the repository. The CLI sets up the connection only, and you add the workflow yourself.
From a linked project directory, connect your Git origin:
bunx prisma git connectTo name the repository explicitly:
bunx prisma git connect https://github.com/acme/shopIf the GitHub App isn't installed yet, the CLI opens the browser to finish the install. The command needs an interactive terminal: it waits for the install to complete, and --no-interactive fails with CLI.INTERACTION_REQUIRED. For headless setups, connect through the Console instead.
Disconnect when you're done:
bunx prisma git disconnectDisconnecting stops the credential exchange and the branch automation. It doesn't delete the project or tear down existing branches.
What the connection does
Once a project is connected:
- Actions runs can authenticate. A workflow job with
id-token: writegets a workspace token through the OIDC exchange. The token is valid for 30 minutes and is only issued for the connected repository; unconnected repositories and forks are refused, and the deploy action then skips with a green run. - Branch created → creates the matching platform branch.
- Branch deleted → tears down the matching platform branch and its resources. Your production and default branches are exempt from this cleanup.
Pushes are not handled by the platform. Your repository's own workflow deploys them, so a connected repo without a deploy workflow deploys nothing. Connecting also doesn't create branches retroactively: it aligns your default branch with the repo's default branch and wires up automation for future events.
What's not supported
GitHub is the only supported provider; others return REPO_PROVIDER_UNSUPPORTED. Pull-request comments and preview comments aren't currently supported.
Next steps
- Deploy on push: the full walkthrough, from connection to per-branch previews.
- Branching: how platform branches map to Git.
- Environment variables: per-branch config for previews.
Domains
Point a custom domain at a production app and the platform verifies DNS and provisions TLS for you.
Preview and staging environments per Git branch (deploy on push)
Test a new version of your app, such as a feature a coding assistant is building, on its own URL without replacing production. With deploy on push, every branch you push other than the default one gets its own preview environment, and the default branch deploys to production.