Job preview-environment-per-pull-request · revised 11 October 2026
Give every pull request its own preview that updates on push and cleans up on close
Each pull request gets a preview with a link on it. A push updates it, closing removes it, and previews use test settings only, with no secrets for fork pull requests.
You might be seeing
- Reviewers approve from the diff and find problems only after merge
- A shared staging site holds whichever branch someone deployed last
No passwords, keys, card details or admin invites needed to start.
What usually happened
There is no automatic running copy of each change. The host may support previews but they are off, scoped to the wrong branches or pointed at production settings; or there is no preview route at all, so a shared staging site is overwritten by whoever deployed last. Preview environments also need safe settings, a rule for cleaning up and a policy for pull requests that come from forks.
Who it’s for: A small team or agency that reviews changes from screenshots and diffs, because nobody can open the running result of a pull request until it is merged.
Usually starts when: Reviewers or clients keep asking to see a change running, or a merged change broke something a preview would have shown.
The result: On a test pull request, a preview is created and linked on the pull request, a second push updates the same preview, closing or merging removes or expires it by the rule you chose, the preview uses non-production settings, and a pull request from a fork receives no secret.
Check whether this job fits
These questions decide whether previews can be created safely with what you already have.
What you get
- A pull request with the configuration and a short operator note
- Links to the test pull request showing the preview link, the update and the removal
- A list of the setting names scoped to previews and the target each points at, with no values
- Steps to turn the automation off
Included
- One repository, one application and one hosting route you already have and that supports previews
- Configure the automation that creates, updates and removes a preview for each pull request, and posts its link on the pull request
- Scope settings per environment so that previews use non-production values that you supply
- Agree and apply the fork pull request policy: no secrets, and no preview that needs them
- Test with a pull request, a second push, a close and a fork-style pull request
Not included
- Creating a hosting account, adding a paid plan or buying a domain
- A separate database for every preview, or copying production data into previews
- A single private feature built and reviewed with you: that is the one-feature preview job
- Production deployment or promotion
- Visual regression testing or load testing of previews
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Opening a test pull request creates a preview of that branch and posts its link on the pull request, within a time agreed before work starts.
Evidence: The pull request showing the link and the preview's address loading the changed page.
A second push to the same pull request updates the same preview, and the link on the pull request still works.
Evidence: Two commit identifiers shown against the same preview address.
Closing or merging the pull request removes or expires the preview by the agreed rule.
Evidence: The preview address after closing, and the platform's record of removal.
Previews use only non-production values and a fork-style pull request receives no secret.
Evidence: The list of setting names and targets without values, and the fork-style run's log.
Your authorised maintainer accepts the evidence and merges the pull request.
Evidence: Your written sign-off and the merged pull request record.
Sign-off. You inspect the test pull request, the cleanup result and the settings list, sign off in writing and merge the pull request. Payment follows sign-off.
If it fails. If a preview is not created, updated and removed as agreed, you do not pay for this fixed scope. If previews can only work with production values or a paid plan you have not approved, we explain it and stop.
When it fits, and when we stop
It fits when
- Your existing host or CI can deploy a copy of the application from a branch to a place you control without a new account or paid service
- Non-production values exist for every outside service the application needs, or you agree which features are off in previews
- A maintainer can approve the test pull request and change the hosting project's settings
- The repository already has CI or a Git integration with the host
We stop and tell you if
- The only way to make a preview work is to point it at production data or production secrets
- The host charges for previews and you have not approved the cost
- Pull requests from forks must receive secrets to be useful: we explain the risk and stop
- The application cannot run without a service that has no test mode
What could go wrong
Before merge, closing the pull request leaves your configuration unchanged. After merge, your maintainer can switch the automation off by reverting the commit, and removing previews that exist follows the cleanup note.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A preview is pointed at production data or services. | Previews read only values you enter for non-production targets, and the reviewer checks the scoped settings list against the targets. |
| A pull request from a fork reads secrets through the preview. | The fork policy gives no secrets and the test run includes a fork-style pull request. |
| Previews accumulate and cost money or stay public. | A cleanup rule is agreed and tested, and access control for previews is set to what the host supports and you choose. |
An independent reviewer checks that no production value is reachable from a preview, that a fork pull request receives no secret and that closing really removes or expires the preview. Your maintainer approves the test pull requests and merges.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the repository, the hosting route, the cleanup rule, the fork policy and the test pull request in writing
- Read the current deploy configuration and list the settings the application needs, with their non-production values to be supplied by you
- Configure creation, update and removal of a preview for each pull request, and the link on the pull request
- Scope the settings so previews read only the non-production values and a fork pull request receives none
- Run the test sequence: open, push again, close, and a fork-style pull request, and record each result
- Have an independent reviewer check the settings, the fork policy and the runs, then hand over the pull request and turn-off steps
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and necessary permissions are in place. Platform, runner and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If previews need regular attention as services change, a monthly rehearsal can open a test pull request and report the result.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Check whether your host already makes previews by default. Vercel documents that it creates a preview deployment for pushes to non-production branches and for pull requests, and that environment variable changes apply only to new deployments. vercel.com
- GitHub environments let you restrict which branches can deploy and hold secrets that only jobs using that environment can read. docs.github.com
Questions
How is this different from the one-feature preview?
That job builds one feature and gives you a private preview of it. This one sets up automatic previews for every future pull request.
Does every preview get its own database?
No. A separate database per preview is a larger change. This job points previews at non-production values you supply.
Can previews be public?
That depends on what your host supports and what you choose. We set access to the level you agree and record it.
Send an enquiry
Send us
- The hosting route in use and whether previews are already enabled
- What the application needs to run: databases, outside services and their test modes
- Who reviews pull requests and whether they come from forks
- Do not send credentials, source code or an access invitation in the first enquiry
Later, once you agree
- The pipeline files and hosting configuration through an authorised company-controlled route
- Non-production setting values entered by you into the host or CI secret store
- Approval of a test pull request, and of the cleanup rule
You own the repository, the hosting project, the settings and the secrets. We work from authorised files on a branch through a company-controlled identity and use values that you enter yourself. We never receive production secrets, and you approve the test pull requests and merge the change.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “preview-environment-per-pull-request” as the subject.