# Deploy After Merge

---

## Deploy after merge

A Task can end at a production deployment instead of a pull request. Tick **After the PR is merged, deploy to production** when you create or start a Task; once you merge its pull request on GitHub, Deployment.io deploys the change to production and checks it there.

The option is off by default. A draft remembers the choice, and **Start** shows it ticked or not as saved.

### When it's available

Deploy after merge works for static sites only, and for repositories on GitHub only. It's available when every repository in the Task has exactly one production static site: a static-site deployment, in an environment classified Production, that builds the same repository from the branch the Task starts from.

Otherwise the checkbox is disabled, and the reason for each repository is shown under it:

- "No production static site deploys <repository> from <branch>."
- "<repository> deploys from <branch> to <environment>, which isn't classified as Production. Classify it as Production to deploy there after merge." An environment's classification is chosen when you create it.
- "More than one production static site deploys <repository> from <branch> (…). Deploy after merge needs exactly one."
- "Deploy after merge follows GitHub pull requests only; <repository> is on <provider>."

The production deployment is found when the Task starts and doesn't change afterwards.

### What happens after you merge

Merging the pull request is the approval. Review and merge it on GitHub as you normally would — Deployment.io never merges it. Deployment.io checks GitHub for merged pull requests about every 10 minutes, so the deploy can start up to 10 minutes after the merge.

Each repository deploys when its own pull request merges. For each one:

1. If the production environment is missing a variable the change needs — the Task's **Before deploying** list — it waits. Add the variable to the environment and the deploy continues within about a minute.
2. If the deployment has [automatic deployment on git push](/docs/dashboard/automatic-deployment-on-git-push/) turned on, Deployment.io doesn't start a second deploy: it follows the first build that deployment starts after the merge. If none has started 30 minutes after the merge, Deployment.io deploys it itself.
3. Otherwise Deployment.io deploys the deployment's branch as it is at that moment, and records the commit that went out. It doesn't pin a commit, so nothing merged in between is rolled back.

A deploy that fails is not retried, and nothing is rolled back automatically: the deployment's own **Deploy** and **Rollback** stay available. A pull request closed without merging deploys nothing.

### QA on production

Once every repository's deploy has finished and at least one went out, Deployment.io runs QA once more, against the production site: it checks the Task's acceptance criteria there and reports. Acceptance criteria come from the spec of a Task converted from an [Assistant session](/docs/assistant/from-spec-to-task/); a Task without them gets a smoke check instead — each production site loads with no page errors and no failed requests to the site itself. It is report-only — it never changes code or rolls anything back.

The browser it uses is read-only. It blocks every request that could change data — anything other than GET, HEAD or OPTIONS — so a form submitted during the check never reaches your server, and a criterion that can only be checked by changing data is reported as not checked.

It checks the deployment's own URL. The deployment's custom domains are allowed too, so a site that redirects to its custom domain still loads.

### What you'll see

The Task page shows "Ends at: Production" (or "Ends at: Pull request").

Under each repository, below its pull request, it shows "Deploys to <deployment> in <environment>", then one of:

- "after merge"
- "Waiting for merge"
- "Waiting for variables: <names>"
- "Waiting for AutoDeploy's build"
- "Deploying"
- "Deployed · <short commit>"
- "Deploy failed"
- "Not deployed", with the reason

A **View build** link appears once there is a build.

On [the board](/docs/tasks/the-board/), these Tasks have their own status tags:

- **Needs action** — "Merge to deploy", "Add 2 variables" (the count varies) or "Deploy failed".
- **Running** — "Deploying".
- **Done** — "Deployed".

A must-fix finding still shows "PR held · must-fix open" first.

---

Source: https://deployment.io/docs/tasks/deploy-after-merge/