Connect
Install the first-party GitHub App on all or selected repositories, then explicitly enable each repository in SandyWP.
SandyWP for GitHub
Tag SandyWP. Review the change in real WordPress.
Mention @sandywp-bot on a pull request and get a disposable WordPress site running that exact commit—without leaving GitHub.
maya-dev
@sandywp-bot deploy
SandyWP bot
✅ SandyWP preview ready
Site: https://checkout-pr-42.sandywp.dev
Commit: 8af24c1 · Available while PR is open
Three steps
Repository to review site
Mention
A trusted owner, member, or collaborator writes @sandywp-bot deploy on an open pull request.
Review
The bot updates one stable comment with the site URL, verified commit, stack, and PR-managed lifecycle.
Exact PR code
The SHA is a contract.
SandyWP reads the current pull-request head, records it, fetches refs/pull/<n>/head, and refuses success when the fetched commit differs. A moving branch never quietly becomes the preview.
Your WordPress base
Latest stable, or start from a Blueprint.
A plain deploy starts from SandyWP's latest-stable WordPress environment. Or allow selected account Blueprints per repository and request one by slug; SandyWP applies it before installing the pull request code.
Lifecycle
Account-owned, temporary by design.
Normal quota
Every preview appears in the sponsoring SandyWP dashboard and uses an ordinary active-site slot.
Access choices
Public site URLs are returned on success. Any repository may explicitly add a reusable wp-admin bearer link with a clear warning.
Automatic cleanup
The preview stays available while the pull request is open, then normal SandyWP cleanup starts when it is merged or closed.
PR Preview vs Git Deployment
GitHub PR Preview
One enabled repository + one pull request → one ephemeral review site. Mention-driven, exact SHA, preserves the preview URL across updates.
Persistent Git Deployment
One long-lived sandbox ↔ one repository connection. Manual/push deploys, branch or tag selection, optional deploy key.
Commands
A small language, on purpose.
@sandywp-bot create a new site@sandywp-bot deploy@sandywp-bot deploy using blueprint: gogh@sandywp-bot login@sandywp-bot delete@sandywp-bot helpSecurity
Short-lived access. Narrow authority.
Only trusted collaborators in enabled repositories can consume quota. The App requests read-only Contents plus read/write Pull requests and Issues access for preview comments and reactions. Installation tokens are minted per job and never persisted, embedded in Git URLs, or placed in worker process arguments and Docker environment.
FAQ
Before you connect
Do private repositories work?
Yes. SandyWP mints a short-lived GitHub App installation token for the claimed worker job. No deploy key or personal access token is stored.
What about pull requests from forks?
SandyWP fetches the base repository pull-request ref. Public forks work without access to the contributor fork. Private-fork access depends on the organization policy and should be verified before rollout.
Does SandyWP run npm or Composer?
No. V1 deploys exactly what is committed. Commit required runtime assets or configure an installable subdirectory.
Can a preview start from my Blueprint?
Yes. The account owner selects which Blueprints are allowed for each repository. A collaborator can request one by slug; a plain deploy still starts from blank WordPress.
Does a preview use quota?
Yes. It is an ordinary account-owned sandbox, appears in the dashboard, and consumes one active-site slot.
Can a PR get wp-admin access?
Yes. Each repository can add a reusable login link on request or with every successful preview. Public repository links are visible to everyone, so the setting is off by default and carries a clear warning.
Make the pull request clickable.
Connect a repository, tag SandyWP, and review the exact commit in real WordPress.