How to Deploy a Pull Request to Staging in One Click
Learn how to deploy a pull request to staging in one click with KazTrack, Laravel Forge, and xCloud—per-PR environments your reviewers and QA team can test.

Shipping confidently starts long before merge. The fastest way to catch regressions is to let reviewers, QA, and stakeholders click around real running code—which means you need to deploy a pull request to staging without a manual SSH dance. In this tutorial you’ll wire KazTrack to Laravel Forge and xCloud so any PR spins up its own staging environment with a single action, and the result posts straight back to the GitHub pull request.
Prerequisites
Before you begin, make sure you have:
- A KazTrack project connected to your GitHub repository, with at least one pull request open.
- A Laravel Forge account (with a server and site provisioned) or an xCloud account—KazTrack supports per-PR deploys to either.
- The
deploys.forge(or equivalent xCloud) feature enabled on your KazTrack plan. Per-PR deploys are a Pro-tier capability. - A KazTrack role that grants deploy permission. RBAC is granular, so a manager or owner role typically carries it; testers may not.
- Your Forge or xCloud API credentials handy to complete the one-time connection.
If you plan to drive deploys from an AI agent later, also grab a KazTrack MCP token with deploy scope—we’ll touch on that at the end.
Step 1: Connect Forge or xCloud to your project
KazTrack treats deployment targets as first-class, project-scoped settings.
- Open your project and go to Settings → Deploys.
- Choose your provider: Laravel Forge or xCloud.
- Paste your provider API token. KazTrack stores it encrypted and never returns it in responses or logs.
- Select the site that should receive PR deployments. KazTrack lists your provider’s sites so you can pick the staging target.
Provider: Laravel Forge
Site: staging.myapp.test
Branch: deploy from PR head
Once saved, KazTrack can map a pull request to a deployable site. That mapping is what makes one-click possible.
Step 2: Open the pull request in KazTrack
Navigate to Pull Requests in the sidebar and click the PR you want to ship to staging. KazTrack pulls live context from GitHub—the diff summary, labels, linked issues, and current workflow state.
This screen is your launchpad. Because KazTrack is GitHub-native, the PR here is the same PR your team sees on GitHub; there’s no parallel copy to keep in sync.
Step 3: Deploy to staging in one click
On the pull request page, find the Deploy to staging action.
- Click Deploy.
- Confirm the target site (KazTrack pre-fills it from Step 1).
- KazTrack hands the deploy to Forge or xCloud, builds the PR’s head branch, and starts tracking the deployment.
That’s the “one click.” Behind the scenes KazTrack calls the provider’s deploy API, records the deployment against this PR, and begins polling status.
Watching the deployment status
You don’t have to babysit a terminal. KazTrack shows live deployment status inline:
- Queued – the provider accepted the job.
- In progress – build and release steps are running.
- Succeeded – the staging URL is live and clickable.
- Failed – KazTrack surfaces the provider’s error so you can retry or fix.
Each PR keeps a history of its deployments, so you can see exactly which commit is live on staging right now.
Step 4: Move the PR into the testing workflow
A staging URL is only useful if the right people know it’s ready. KazTrack maps workflow states to GitHub labels and syncs them back automatically, so updating state here updates GitHub too.
- Set the PR’s workflow state to ready_for_testing.
- KazTrack applies the matching GitHub label on the real pull request.
- Your QA team filters their queue by that label and picks it up.
The flow your team will follow is:
ready_for_testing → in_progress → passed
↘ failed
When a tester starts, they move it to in_progress; on success it becomes passed, on a bug it becomes failed—and every transition writes the corresponding label back to GitHub.
Step 5: Let QA test and report on the staging build
Now the staging environment earns its keep.
- A tester opens the PR in KazTrack, starts a working-time timer, and begins exercising the staging URL.
- They run through QA test cases—either hand-written suites or AI-generated cases tied to this PR.
- Findings get posted as comments that land on the real GitHub PR, so the author sees them in context.
- When testing wraps, the tester stops the timer; the time is captured for later reports by tester, day, repository, PR, or label.
If a bug surfaces, the author pushes a fix, you click Deploy again, and the new commit replaces the old one on staging. The loop is tight because every step lives on the same pull request.
Step 6 (optional): Trigger the deploy from an AI agent
Because KazTrack is AI-native through its built-in MCP server, you can let an agent do Steps 3–4 for you. Connect Claude Code, Codex, or any MCP client with a project token that has deploy permission, then prompt:
“Deploy PR #214 to staging, set it to ready_for_testing, and tell me when the build is green.”
The agent calls KazTrack’s deploy tool, watches status, flips the workflow label, and reports back—all bounded by what the token is allowed to do. It can never exceed the permissions of the user who created it.
Troubleshooting
- Deploy button is missing or disabled? Check that your role carries deploy permission and that the Pro-tier deploy feature is enabled.
- Deployment failed immediately? Re-check the provider token in Settings → Deploys; an expired or revoked token is the usual culprit.
- Staging shows an old commit? Confirm the PR’s head branch advanced and deploy again—each deploy targets the current head.
Key takeaways
- Connect Forge or xCloud once in Settings → Deploys, and any pull request becomes deployable.
- One click hands the build to your provider, tracks live status, and ties the deployment to the PR.
- Workflow states map to GitHub labels and sync back automatically, so QA and reviewers stay in lockstep.
- Time tracking and PR comments keep the whole review-and-test loop on a single pull request.
Ready to give every pull request its own staging environment? Spin up a KazTrack project, connect your Forge or xCloud account, and ship your next PR to staging in one click.