What a preview is for
A preview is a running copy of one change, reachable at its own address, so that a reviewer or client can use it before the change is merged. On a hosting platform with a Git integration, a preview is typically created automatically for each push to a non-production branch and for each pull request, with its link posted on the pull request. If your team still reviews from diffs and screenshots, the question is not whether previews are possible but whether they can be made safe, because a preview runs real code with real settings.
The setting that matters most: which values a preview reads
Every outside service the application talks to needs a value, and each environment can hold its own. If previews read the same values as production, a reviewer clicking around a preview can send real emails, write to the real database or charge real cards. Scope values by environment: previews get test or sandbox values for every service, and where no test mode exists, that feature should be switched off in previews. On Vercel, Preview values can apply to all non-production branches or to a single branch, with the branch value winning. Note that staging a production build for a final check uses production values, so it can reach production data by design.
Another detail catches people out: a changed value applies only to deployments made after the change. An older preview keeps the values it was built with, so a corrected setting is not proof that an existing preview is safe.
- Test or sandbox values for every outside service
- Features with no test mode are off in previews
- A changed value reaches only later deployments
Pull requests from forks
Code in a pull request runs in the preview. If the pull request comes from outside your team, that code is untrusted. GitHub gives runs triggered from a fork no secrets except its built-in token, and your preview automation should follow the same rule: either no preview for fork pull requests, or a preview that needs no secrets. Never route a workaround that hands a fork pull request your values.
Cleanup, access and cost
Decide how a preview ends before you create the first one: removed when the pull request closes, or expired after a number of days. Previews that never end accumulate cost and stay reachable. Decide who may open one: your host may protect previews behind a login, or leave them open to anyone with the address, and the right level depends on what the change shows. Check the platform's current settings rather than assuming, and record the choice.
How the paid outcome is accepted
The fixed job sets up previews for one repository and one existing hosting route. It is accepted when a test pull request gets a preview and a link within an agreed time, a second push updates the same preview, closing it removes or expires it by the agreed rule, previews use only non-production values, and a fork-style pull request receives no secret. It starts at £695, untested, and is paid after you sign off. It does not create hosting accounts or buy paid plans. If you want one new feature built and reviewed in a private preview, that is the separate one-feature job.
Sources and limits
- Vercel environments Checked 2026-10-11.
- A preview deployment is created for pushes to non-production branches and for pull requests; a staged production deployment uses production environment variables, so testing can reach production services and data.
- Vercel environment variables Checked 2026-10-11.
- Variable changes apply to new deployments only; Preview variables can apply to all non-production branches or one branch, with a branch value overriding the general one.
- GitHub: using secrets Checked 2026-10-11.
- Runs triggered from a fork receive no secrets except the built-in token.
- GitHub environments Checked 2026-10-11.
- Environment secrets are available only to jobs that use the environment, and deployment branches can be restricted.