Skip to main content
The reintersect/deploy@v1 Action checks and deploys your app. It authenticates with GitHub’s OpenID Connect token, so your repository holds no Reintersect secret. For a hosted app a deploy uploads the bundle. For a self-hosted app it syncs the manifest and endpoint; deploy your server in the same workflow, before this step.

Set up

1

Trust the repository

In Settings → Developer → Apps → your app → Versions → Deploy from GitHub, add the repository (owner/name). Optionally limit it to a branch or tag (a branch name, or a full ref such as refs/tags/v1.2.0), a GitHub environment, or both. An app trusts up to 10 repositories.Reintersect only issues deploy tokens to workflow runs from a trusted repository that match its ref and environment, when set. For pull requests, the ref is the pull request’s base branch. If the repository isn’t visible to your workspace’s GitHub connection, the dashboard warns that anyone who can push to it can deploy the app, and asks you to confirm.
2

Add the workflow

Projects created with npm create reintersect@latest already include .github/workflows/reintersect.yml:
.github/workflows/reintersect.yml
This is the npm version; the pnpm and Bun versions install the same way. Dependencies install frozen to the lockfile when one exists (npm ci, pnpm install --frozen-lockfile, bun install --frozen-lockfile), and unfrozen when there is none yet, so the first push of a new project works.Set the repository variable REINTERSECT_APP_ID to your app’s id. id-token: write lets the job request a GitHub OIDC token, which the Action exchanges for a deploy token that lasts 15 minutes. pull-requests: write lets it comment. The Action runs the reintersect CLI from your project’s dependencies, so install them first.
3

Set environment values

Set environment values for the preview and production environments with reintersect env set or in Settings → Developer → Apps → your app → Environment. A deploy fails if a required variable has no value in the target environment.

Inputs

Outputs

When a run may deploy production

Reintersect decides on its side, from the OIDC token, and the Action can’t override it:
  • Only push and workflow_dispatch runs can deploy production. Pull request runs are always previews.
  • With a branch or tag pinned, only that exact ref deploys production.
  • Without a pinned ref (“Any branch”), only the repository’s default branch and tags deploy production; other branches get previews. If Reintersect can’t tell the default branch, the repository is preview-only.
  • The rule is checked again every time the deploy token is used.
A run that asks for production but may only deploy previews fails with a message that says so.

Pull request previews

Every pull request push deploys a preview version and updates one comment on the pull request with the version, its status and a link to the playground. Pull request previews never move any install, including development installs; reviewers open the link and pick Run vN in the playground to try it on their own development install. See Previews and versions.

What the Action checks

Before deploying, the Action runs reintersect check --json signed in with the deploy token, so the full validator runs. Errors fail the job and every finding becomes an annotation on the file and line it points at. See reintersect check for the list.

Production deploys

A production deploy publishes the new version. Installs move to it when it asks for no more access than they approved; otherwise they wait for an admin, and the Action’s log says some installs need review. See Publishing new versions.