Skip to main content
SandyWP for GitHub creates an account-owned temporary sandbox from the exact head commit of an open pull request. It is available on paid plans and uses the connected account’s normal site quota.

Connect and configure repositories

Open Account → GitHub, select Connect GitHub, then grant the GitHub App access to the repositories you intend to use. Enable preview commands for each repository explicitly. Choose whether the preview deploys a plugin, theme, or wp-content folder. The source path must be a committed, installable subdirectory; preview builds do not run npm, Composer, or other build steps.

Allow Blueprints deliberately

Each repository has an allow-list of account Blueprints that commenters may request. GitHub commenters cannot browse other account Blueprints or use a recipe that the owner has not selected. A plain deploy uses a blank WordPress preview. A requested Blueprint creates the base first, then SandyWP installs the pull request code into it.

Commands

Only repository owners, members, and collaborators can run commands. The pull request head is authoritative, so branch-selection commands are rejected.

Lifecycle and access

A preview exists while the pull request is open. Closing or merging the pull request requests normal cleanup; @sandywp-bot delete removes it sooner. Redeploying a new commit normally updates the existing preview site and preserves its URL and database. Requesting a different Blueprint or revision replaces the preview so recipe state is never layered unpredictably. A repository can choose Never, Only when requested, or With every successful preview. The default is Never.
A wp-admin URL is a reusable bearer link. GitHub comments can be copied into notifications, logs, and API responses; never enable a login link for a preview with sensitive data, especially in a public repository.

Troubleshooting

Disconnecting stops new commands. Choose deletion during disconnect, delete previews manually, or close their pull requests to remove active previews.