What’s new at SandyWP.

Add a share image URL under Customize landing page. When someone posts your demo link on X, LinkedIn or Slack, the preview uses that image along with your headline and subhead.

Choosing Latest in the version picker now installs WordPress 7.1.3. You can also pin 7.1.3 exactly through the API, CLI and MCP.

A live WordPress 7.x read used to fail the whole status payload when the multisite check printed extra lines. sandywp_site_status now reads MULTISITE from wp-config, treats an unknown result as single-site, and still returns the installed version, active theme, and plugins. Running PHP stays on site.phpVersion.

On the ChatGPT connector, sandywp_magic_login mints a 15-minute login URL that the sandbox helper invalidates after the first successful login. Cursor and Claude keep the reusable site-lifetime link. Consent for that ChatGPT connection now says it generates single-use, short-lived wp-admin login links.

https://app.sandywp.com/mcp/openai now tells ChatGPT what SandyWP sandboxes are, to poll site and job status, to use sandywp_magic_login for wp-admin links, to confirm destructive tools, and to check sandywp_get_account before creating sites. Cursor and Claude at https://app.sandywp.com/mcp still use the longer connect recipe.

sandywp_bake_blueprint is no longer on the ChatGPT connector. Cursor and Claude still have it on the main connector.

https://app.sandywp.com/mcp/openai advertises sandywp_get_account (plan, sandbox limits, and current usage) instead of sandywp_whoami. Cursor and Claude still have sandywp_whoami on the main connector.

The ChatGPT connector no longer includes sandywp_save_email_relay, sandywp_test_email_relay, or sandywp_delete_email_relay. sandywp_get_email_relay still shows the masked password hint only. Save a relay from Account, Email delivery, or from Cursor and Claude.

https://app.sandywp.com/mcp/openai no longer returns magicLoginUrl, adminUsername, or admin password fields from list, create, status, restore, or other site payloads. sandywp_magic_login still returns a login URL when you ask for one. Cursor and Claude at https://app.sandywp.com/mcp are unchanged.

Approving the connector at https://app.sandywp.com/mcp/openai no longer includes permission to run shell commands in your sandboxes. Cursor and Claude at https://app.sandywp.com/mcp are unchanged.

sandywp_apply_patch on the ChatGPT and Codex connector uses the same permission as writing files. The main connector still uses the shell permission for that tool.

https://app.sandywp.com/mcp/openai no longer advertises sandywp_configure_template_launcher. Cursor and Claude still have it on the main connector.

https://sandywp.com/legal/privacy#ai-connectors explains what ChatGPT, Claude, and Cursor can access through MCP, that we do not store your chat conversations, how to revoke OAuth tokens, and how to delete your data.

When Claude, ChatGPT, Cursor or the Cloner plugin asks to connect, choose the workspace on the approval screen. It defaults to the workspace you have open in the dashboard.

A connection never acts outside the workspace you picked. If you leave that workspace, the connection stops working instead of falling back to your personal workspace. Connect again to use another workspace.

Point ChatGPT or Codex at https://app.sandywp.com/mcp/openai. It is the same SandyWP connector and the same OAuth login, without a generic sandbox shell tool. tools/list is the same named catalog whether you are scanning or signed in.

Cursor, Claude, and other clients at https://app.sandywp.com/mcp can run sandbox shell commands again (wp-cli and similar) with the exec:write permission. ChatGPT does not see that tool.

whoami, usage, template leads, and test email on https://app.sandywp.com/mcp/openai still hide emails, user ids, lead ids, and IP hashes. The main connector at /mcp returns those fields again.

WP-CLI prints plugin and theme JSON without a final newline, which used to glue the next section marker onto that JSON and hide the plugin list. Site status now inserts a newline before each marker and still parses the JSON if notices wrap it.

On the ChatGPT connector, sandywp_site_status only takes a site id. Use sandywp_magic_login for a wp-admin link. Cursor and Claude still have includeCredentials on the main connector.

Select Explain errors under a sandbox's debug log. Claude reads the newest entries and tells you what broke, which plugin or theme caused it, and how to fix it.

Choose Describe in New Blueprint and write what you want in plain words. Claude writes the Blueprint, SandyWP validates it, and you can edit the JSON before saving.

The SandyWP Slack bot now runs on Claude, so it understands requests like deploying an attached plugin to a new site more reliably.

tools/list on https://app.sandywp.com/mcp always returns the same named tools, with read-only, destructive, idempotent, and open-world hints on every entry. Calling a tool still requires the matching OAuth scope.

sandywp_exec is no longer on the connector. Push code with sandywp_apply_patch, edit files with the file tools, read WordPress details from sandywp_site_status, and use the SandyWP CLI for a shell.

sandywp_whoami and sandywp_usage return plan, limit, and active sandbox count only. Template leads return a count and masked emails. A test email reports success without the destination address.

Add your SendGrid, Elastic Email or other SMTP account in Account, Email delivery. Mail is sent from your provider on your account, never from SandyWP.

Switch on Deliver real email in a sandbox's Email tab, or with one API or MCP call. Every message still shows up in the Email Log, and sandboxes stay capture-only until you choose.

Open a sandbox, choose the Custom Domain tab, and enter a domain like demo.example.com. Add the one DNS record SandyWP shows you, and the domain goes live with a free SSL certificate.

Disconnect a domain from one sandbox and connect it to another, so the links you share never change when you rebuild a demo.

Upload a theme ZIP or connect a theme repository on GitHub, the same way you add a plugin. SandyWP reads the ZIP to tell a theme from a plugin, and installing a theme activates it on the sandbox.

The Plugin Library is now called Library in the app menu. Your CLI, API and agent commands work as before, and agents can install themes with the same sandywp_deploy_plugin call.

The new sandywp_create_clone_code tool gives your agent a clone code for one site. It installs SandyWP Cloner on that site, pastes the code, and clicks Clone, and the copy lands in your account.

A clone code works for that single clone and expires after two hours. It cannot see your other sandboxes or clones, so the site owner never gets access to your account.

Bake a Blueprint whose landingPage is a path inside the sandbox, such as /wp-admin/plugins.php, and the Template opens public demos there. Every rebake applies it again, replacing a destination you set by hand.

A landingPage that points outside the sandbox now shows a warning when you validate the Blueprint, and SandyWP ignores it. Creating a sandbox or applying a Blueprint to one still ignores landingPage, as before.

For a ready sandbox, sandywp_site_status returns the installed WordPress version, a multisite flag, and every plugin with its version and status (active, inactive, network-active, must-use, or drop-in). Agents no longer need to run WP-CLI just to find out what is installed.

Polling a sandbox no longer returns the admin password or login link. Pass includeCredentials: true when you need them, or call sandywp_magic_login for a fresh link with its expiry.

A ready sandywp_preview_github_pr result now returns magicLogin with both the url and expiresAt, the same shape as sandywp_magic_login.

sandywp_apply_patch takes the plain output of git diff and applies it inside a plugin or theme folder, including new and deleted files. Pass dryRun to check it applies first. It needs the exec permission when you connect.

Open a plugin's actions menu on the Plugins page and choose Set license key, or add the key while adding the plugin. Keys are encrypted at rest and write-only: the dashboard, API, and CLI only ever show the last four characters.

Agents read a key with the new sandywp_get_plugin_license MCP tool, which needs the new licenses:read permission when you connect. Every read is recorded in your workspace audit log, and the Plugins page shows when an agent last read each key.

A new Plugins page keeps the plugins you reuse, such as premium ZIPs or your own private plugins. Upload a ZIP (uploading again under the same name replaces it) or add a GitHub repository, and every install pulls the .zip asset of its latest release.

Ask your agent to "install gravityforms on my-shop": the MCP server lists the library with sandywp_list_plugin_library and installs with libraryPlugin on sandywp_deploy_plugin. The CLI adds sandywp library and sandywp deploy <site> --library <name>.

Run WP-CLI inside a sandbox without opening a shell: plugin list, eval, db query, and eval-file for local PHP fixtures. --path and the sandbox public URL are supplied automatically, output and the remote exit code pass through for test runners, and eval-file uploads land in a temporary path that is removed afterwards.

Deploying a plugin ZIP (CLI deploy, sandywp_deploy_plugin, Slack ZIP deploy) uploads the file to SandyWP. Those uploads used to be kept forever; each is now retained for 24 hours so a retry or a second deploy can reuse the same artifact, then both the stored file and its record are deleted automatically. Deploying again after that window simply re-uploads the ZIP. Deleting a sandbox no longer leaves its upload behind either.

A wp-admin login link is a bearer credential: anyone holding it can log in until it expires (the sandbox expiry, or about 10 years on permanent sites). They were previously described as one-time links. The CLI, dashboard, Slack replies, GitHub preview comments, and the sandywp_magic_login MCP tool now print a shared warning with the actual expiry. Treat login links like passwords and share them only with people who should have wp-admin access.

The sandywp_deploy_plugin MCP tool now waits up to a minute and returns the finished deploy, including failures with a clear error. Pass background: true to keep the old queue-and-poll flow.

The tool accepts a wordpress.org slug, a staged artifact id, or a public ZIP URL. The base64 upload option never fit through the request limit, so it was removed; for a local ZIP keep using sandywp deploy from the CLI.

Choosing Latest in the version picker now installs WordPress 7.1.2. You can also pin 7.1.2 exactly through the API, CLI and MCP.

Choosing Latest in the version picker now installs WordPress 7.1.1. You can also pin 7.1.1 exactly through the API, CLI and MCP.

Scoped MCP tokens with sites:read no longer include magic-login links or admin passwords in site status or list responses. Grant sites:login (or call sandywp_magic_login) when the assistant should open wp-admin. Cloner import tokens are unchanged: import-only scopes still receive a login URL when a clone is ready. If your token mixes import:read with any sites:* scope, you need sites:login for that URL.

Each worker VPS uses its own fleet token. Main validates against SANDYWP_WORKER_TOKENS; changing a map entry revokes the old credential without waiting for a code deploy.

Job claims carry only the per-sandbox secret injected into the container, not the master used to mint magic login and file-manager tokens.

This release changes how sandbox signing keys are derived. After deploy, drain and refill the warm pool and recreate every sandbox container (for example PHP version flip-and-back). Until then, sites stay up but magic login and file/DB dashboard tools return 403.

Select a folder and choose Compress, from the toolbar or the right-click menu, to zip it inside the sandbox and download the archive. Downloads used to be one file at a time, so pulling a plugin directory off a sandbox meant SFTP or a file-by-file crawl. The zip is built on the sandbox, streamed to you, then deleted. The limit is 256 MB uncompressed or 20,000 files per folder.

A sandbox you create without signing in now expires one hour after creation, down from seven. Anonymous sandboxes are throwaway by nature, and a shorter window keeps far less unattended WordPress running on our domains. Sandboxes created while signed in are unchanged: a week by default, and anything from one hour to permanent at create time.

Signing in lifts the limit rather than extending it. A free account gets up to a week per sandbox and chooses the lifespan at create time, so nothing you are still working on disappears on you.

When SandyWP understands your request but is not fully certain, it now describes the exact plan and waits. Reply yes and it builds precisely what it described, or correct it and carry on. Nothing is provisioned on a guess.

Instead of a fixed command list, SandyWP now asks for the one thing it is missing, in plain language, referring to what you actually said.

Ask what SandyWP can do, which WordPress or PHP versions are available, or how to phrase a request, and get an answer in the thread rather than a link to the docs.

Describe the sandbox you need, including WordPress, PHP, and plugins. With AI interpretation enabled, SandyWP translates your request into a validated action. Unclear requests get a clarification before anything runs.

Say create a sandbox with these 2 plugins, including ZIPs uploaded earlier in the thread. SandyWP creates one sandbox and installs the selected files in order. If an install fails, the bot stops and reports which plugins succeeded.

Say @SandyWP create a new site from template client-base, or use the compact form @SandyWP create a new site, name: my-demo, template: client-base. The new sandbox starts from your template instead of a blank WordPress, and a plugin ZIP attached to the same message is deployed onto it. @SandyWP list my templates shows the names you can use.

When the bot cannot act on a mention, the reply now ends with a link to the Slack command guide, so a wrong phrasing no longer needs a separate help request.

The single-use login URL is now posted as an ephemeral Slack message visible only to the person who asked, instead of to the whole channel.

Create a sandbox, create a website, spin up an instance, and set up a new environment are all read as a request for a NEW sandbox, instead of a lookup for a site with that name.

New sandboxes created with the latest option now install WordPress 7.1. The warm pool follows it too, so a 7.1 sandbox is still ready in seconds, and 7.0 and 6.9 remain selectable as the two previous stable release lines.

The first visit after signup now opens a two-step accelerator at /onboarding: pick your name and avatar and say what you do, then name the sandbox and hit Create. The sandbox builds in place on the latest WordPress and PHP 8.3, and the screen turns into a ready state with a magic-login button. The whole flow is skippable — Take me to the dashboard goes straight there, and you are never sent back.

The dashboard now carries a slim bar with the three setup steps: create your first sandbox, confirm your email, invite a teammate. It shows what is left in one sentence with the matching action beside it, and it disappears for good once you finish the steps or dismiss it.

The preview release in the create dialog is now WordPress 7.1 RC 4, so you can certify your plugins and themes against the latest release candidate before WordPress 7.1 ships. Preview releases are always built fresh on demand rather than served from the warm pool, so they take a little longer to launch.

The preview release in the create dialog is now WordPress 7.1 RC 3, so you can certify your plugins and themes against the latest release candidate before WordPress 7.1 ships. Preview releases are always built fresh on demand rather than served from the warm pool, so they take a little longer to launch.

New sandboxes created with the latest option now install WordPress 7.0.4. The warm pool follows it too, so a 7.0.4 sandbox is still ready in seconds, and 7.0 and 6.9 remain selectable as the two previous stable release lines.

New sandboxes still get a random name like lazy-pail, but you are no longer stuck with it. Pick Rename from the actions menu on My sites, or click the pencil next to the title on a sandbox detail page. This changes the display name only: the sandbox URL, the slug, and your admin login are untouched, so nothing you have open or bookmarked breaks. The API accepts it too — PATCH /api/app/sites/:id with a name field.

New sandboxes created with the latest option now install WordPress 7.0.3. The warm pool follows it too, so a 7.0.3 sandbox is still ready in seconds, and 7.0 and 6.9 remain selectable as the two previous stable release lines.

The preview release in the create dialog is now 7.1 RC 1, the last stop before WordPress 7.1 ships. This is the build worth certifying your plugins and themes against. Preview releases are always built fresh on demand rather than served from the warm pool, so they take a little longer to launch.

Every new sandbox is created with the /%postname%/ permalink structure and the matching rewrite rules in place. Previously sandboxes used WordPress's raw default (plain permalinks) with no rewrite config, so any pretty URL — a feed, a sitemap, /wp-json/, or an XML or callback endpoint generated by a plugin — returned a server 404 before WordPress ever saw the request. Plugins that behaved correctly on other hosts now behave the same way here. You can still change the structure under Settings → Permalinks at any time.

PHP 7.4 now appears alongside 8.1, 8.2, and 8.3 wherever a PHP version is chosen: the create dialog, the PHP configuration panel, the API, the CLI, and the MCP tools. It runs the same pinned WordPress core as every other sandbox, so you can reproduce a customer report on a legacy stack without leaving SandyWP. PHP 7.4 reached end of life upstream in November 2022 and receives no security fixes — it is offered for compatibility testing, not for anything long-lived.

Configure a callback under Account → Webhooks → Demo Launches. SandyWP sends a signed demo.ready event after a visitor opens a public launch link and the sandbox is ready, including the templateId, working siteUrl, and captured email when the launch form collected one. Requests include an HMAC signature, idempotency key, and automatic retries so your CRM or automation workflow can safely consume the event.

Public launch links now create protected demos by default. Visitors still get a real wp-admin to click around in, but the plugin and theme installer, the ZIP uploader, and the built-in file editor are switched off — so the premium plugin your demo exists to show off cannot simply be downloaded from the dashboard. Find the Protected demo toggle in the Share a public demo dialog on any template, and turn it off if a particular demo needs a full-powered admin.

From URL previously accepted only a blueprint.json document. Point it at a URL that serves a ZIP bundle and SandyWP now downloads the archive and imports it exactly as an uploaded bundle — the same 50 MiB, 250 MiB expanded, and 2,000 entry limits apply. The API accepts a bundleUrl field on POST /api/app/blueprints/upload.

WordPress Playground documents bundled resources as {"resource":"bundled","path":"/theme.zip"}, where the leading slash means the bundle root. SandyWP treated that as an escape and refused the Blueprint. Those paths now resolve against the blueprint.json folder, for both uploaded bundles and URL imports. Paths that genuinely escape the bundle are still rejected.

sandywp blueprint (list, get, create, update, delete, import, validate, bake, runs) and sandywp template (list, get, delete, launch) are now available. sandywp blueprint bake --wait polls until the bake finishes, so a CI job can rebuild a demo site on every push. Available in @sandywp/cli 0.5.0.

Assistants connected over MCP can now list, author, validate, import, and bake your Blueprints, and create sandboxes from them. If you already have SandyWP connected, disconnect and reconnect once to grant the new Blueprint permission — the new tools stay hidden until you do.

The API docs now cover every endpoint, including Blueprints, Templates, launch links, debug tools, and imports — each with request fields, responses, and curl examples, plus an end-to-end script for the bake-and-share workflow. A build check keeps the reference in step with the API from now on.

DELETE /api/app/templates/:id now returns a 404 when the Template does not exist, instead of a success status with an error in the body. API clients that check the status code will notice the difference.

Everyone in a Workspace sees every sandbox, with billing and membership kept at the Workspace boundary.

Owners can create roles that grant sandbox lifecycle, internals, reusable assets, integrations, and member management.

Sandbox sites now capture outgoing wp_mail() messages instead of silently dropping them. Open the Email Log tab on any site to see the subject, recipient, time, and the full rendered message — so you can confirm a contact form, password reset, or order receipt actually fired. Mail is always captured safely inside the sandbox and never delivered to real inboxes. You can toggle capture off and clear the log at any time.

The preview release in the create dialog is now 7.1 Beta 3, so you can retest your plugins and themes against the newest 7.1 build before the stable release arrives. Preview releases are always built fresh on demand rather than served from the warm pool, so they take a little longer to launch.

List plugin slugs after install or with in your mention, for example: @SandyWP create a site name: plugin-test, install this, and publishpress-authors, post-expirator. Up to 10 slugs are installed and activated on the new sandbox, and they work alongside a plugin ZIP attached to the same message.

A slug that is not on wordpress.org now stops the create and comes back with a suggestion: I could not find publishpress-author, did you mean publishpress-authors? Nothing is provisioned until you fix it, so you never end up with a sandbox missing the plugin you wanted to test.

Because a bare slug after install now reads as a plugin name, deploying a ZIP to a sandbox you already have takes install this to my-demo.

Say @SandyWP install publishpress-authors, post-expirator on my-demo to install and activate several plugins without rebuilding the sandbox. Separate up to 10 slugs with commas or and; omit the site to use the existing-site picker.

New sandboxes created with the latest option now install WordPress 7.0.2. The warm pool follows it too, so a 7.0.2 sandbox is still ready in seconds, and 7.0 and 6.9 remain selectable as the two previous stable release lines.

The preview release in the create dialog is now 7.1 Beta 2, so you can retest your plugins and themes against the newest 7.1 build before the stable release arrives. Preview releases are always built fresh on demand rather than served from the warm pool, so they take a little longer to launch.

The Deploy menu can now target any tag from your repository, not just a branch. Pick a tag from the new Branches/Tags picker and SandyWP clones exactly that release into your site as a one-off it does not change the branch you deploy on push.

The deployment history and the last-deployed line now show a distinct chip for tag deploys, so you can tell at a glance whether a run shipped a branch or a tagged release.

sandywp.com/llms.txt gives AI agents a directly actionable quickstart: create sandboxes via the CLI, connect over MCP, deploy plugins, and use instant plugin/theme launchers — no docs digging.

The homepage now has a copy-paste prompt for Claude, Cursor, Codex, and other assistants — paste it and your agent hands you a live WordPress sandbox URL.

sandywp deploy (and every other CLI command that targets a sandbox) now accepts the site ID as well as the slug, so tools that only know the ID can deploy directly. Available in @sandywp/cli 0.4.1.

When an assistant connected over MCP tries to deploy a plugin ZIP from your machine, SandyWP now points it to the CLI upload path instead of inlining the file as base64 — faster, cheaper, and no size squeeze.

Launch a disposable beta sandbox and check your plugins and themes before the stable release arrives.

New sandboxes and the warm pool now follow 7.0.1, with 7.0 and 6.9 kept ready as the two previous stable versions.

Admins can publish targeted, scheduled announcements with optional images, videos, and calls to action.

Release notes now have their own multi-update changelog and CRM workflow, separate from temporary product notifications.

Signed-out visitors can now reach SandyWP login directly from the public navigation.

Homepage, dashboard, action menus, and progress modals now use more deliberate motion and feedback.

Email signup includes required terms acceptance and an optional marketing choice, while Google signup shows its terms notice directly beside the action.

A new public page explains the WordPress cloning workflow and provides a focused path to get started.

The public site now uses SandyWP's sandcastle-beach visual direction with a clearer product story.

Authentication pages use a focused split-screen layout with a continuous SandyWP beach scene.

The public footer now closes the experience with SandyWP artwork and a clearer email call to action.

Update deployment settings inline, choose repository branches, and run one-off branch deployments from the site page.

CLI mount behavior is optimized for faster directory access and more dependable startup on macOS.

Debug-log entries display clear severity badges and can be filtered to the messages that matter.

Toggle WP_DEBUG options for an existing sandbox and inspect or clear debug.log from its site page.

Return a sandbox to a clean installation with one confirmed action while keeping its SandyWP identity.

Open an authenticated shell in a ready sandbox without manually assembling SSH credentials.

Mount a sandbox as a local filesystem for editing with desktop tools and IDEs.

Use compatible SFTP clients and filesystem tools to work directly with an opted-in sandbox's files.

Connect SandyWP through OAuth and create, inspect, configure, and retire sandboxes from Claude.

Preinstalled plugin or theme requests no longer require a full cold WordPress installation.

Workers cache downloaded plugin and theme packages, making repeat installations faster.

The progress bar advances with plugin and theme installation steps and uses clearer setup language.

Cloner displays a real progress bar and live messages while SandyWP restores the database and files.

Suspended sandboxes can be restored while their retained data is still available.

Sandbox rows now have a context menu for quick access to common site operations.

Shift-click selects or deselects a range of sandbox rows for bulk actions.

Dashboard, account, import, and template workflows report success and errors through shared toast notifications.

Connect Cloner through secure browser authorization instead of manually copying an API token.

Cloner adds size and time estimates, configurable exclusions, upload progress, failure guidance, and recent clone history.

Search WordPress.org and preinstall up to ten plugins directly from the create-site modal.

Creation status names each plugin as it installs and shows its position in the queue.

Contact SandyWP support without leaving the account page.

Visiting /plugins/<slug> creates a branded sandbox with that WordPress.org plugin installed and activated.

/themes/<slug> provides the same one-click flow for WordPress.org themes.

Preinstalled plugin and theme selections carry through both account and guest creation paths.

The homepage demonstrates permanent sites, file editing, Git deployment, templates, cloning, CLI, and Slack workflows.

Pricing explains which advanced tools and longer sandbox lifespans are included with paid plans.

Saving and restoring templates remains available to everyone; publishing a reusable public launch link requires a paid plan.

Install the SandyWP app and securely link individual SandyWP accounts from Slack or account settings.

Mention SandyWP alongside a ZIP file and choose a new or existing sandbox for deployment.

Use @SandyWP deploy with a branch name to deploy repository work to a sandbox.

Slack commands can create, list, and delete SandyWP sites with in-thread confirmation.

sandywp push packages a local installation and synchronizes it into a SandyWP sandbox.

CLI-created sites now return a terminal-clickable automatic-login URL.

Version information is available through --version, -v, or the version command.

Locked developer tools now explain paid-plan availability before interaction.

Verification and password-reset messages now use a consistent SandyWP design.

New sandboxes and Cloner imports can run WordPress Multisite in subdirectory mode.

User-entered sandbox names keep a clean, suffix-free address when that slug is available.

Open, download, rename, and delete files from the File Manager context menu.

Adminer now uses SandyWP branding and a purpose-built visual theme.

Profile, security, API, billing, and integration settings now live on a focused account page.

Automatically generated sandbox addresses no longer expose account emails and include an unguessable suffix.

Sandboxes created without a supplied name receive a memorable random name instead of a generic default.

Successful warm-pool claims are revealed immediately and show the server-measured creation time without stopwatch flicker.

Long sandbox URLs no longer cause horizontal overflow on smaller screens.

New users confirm their email address before their first login through a dedicated verification flow.

Database exports tolerate stricter SQL modes, and sandboxes include PDO MySQL support required by many plugins.

SandyWP remembers the last-used region, duration, mode, and advanced-settings state. Site-detail tabs also survive refreshes.

Sandbox names in the dashboard are direct links to the full site-management view.

Delete, copy, permanence, template, and SSH operations now provide consistent toast feedback.

Enable SSH for a ready sandbox and connect only to that sandbox's isolated container.

Add and revoke account public keys from the site dashboard, with common RSA and modern key types supported.

Copy a ready-to-run connection script from the redesigned SSH panel.

Database and wp-content data stream directly in parts instead of requiring one large local archive first.

Follow actual upload and restore progress in the Cloner until the new sandbox is ready.

Batched exports and parallel multipart uploads substantially improve large-site clone speed.

Canceling from the plugin stops both the transfer and SandyWP restore job.

Compare monthly and yearly pricing on the homepage and choose annual billing at checkout.

Review environment checks and an activity log before and during a clone.

If the standard workflow is blocked by a site's configuration, retry with an alternative cloning path.

Select a lifespan from one hour through seven days, with permanent sandboxes available to eligible paid accounts.

Upload into the selected folder, create files, and copy or paste files without leaving SandyWP.

See upload progress, keep expanded folders, scroll large trees, and confirm deletions in-app.

Faster loading, better scrolling, theme-aware syntax highlighting, save confirmations, and clearer read-only states.

PHP settings explain the brief sandbox restart and confirm completed changes with an in-app notification.

Connect a repository, deploy manually or on push, review history, and use generated deploy keys for private repositories.

Browse and edit sandbox files in the dashboard and open the database tool with automatic login.

Change the PHP runtime for an existing sandbox from its PHP configuration panel.

Open a sandbox URL or jump straight into WordPress admin from the site detail header.

The cloning plugin received its new name and a redesigned WordPress admin experience.

Exclude uploads, revisions, unwanted comments, inactive themes, or inactive plugins to make a clone smaller and faster.

Stop an in-progress clone, retry it, delete old import records, and open the resulting sandbox directly.

Authenticate, create and list sandboxes, open WordPress admin, follow provisioning, and delete sites from the terminal.

Create and revoke API keys from the Account modal for CLI and API integrations.

Install the SandyWP connector on a WordPress site and send a complete copy into a fresh SandyWP sandbox.

Resilient chunked object-storage transfers restore large sites under their new SandyWP URL.

Create sandboxes on the new Southeast Asia server, or let SandyWP choose an available region automatically.

Generate a fresh one-click WordPress admin login whenever you need it, including after an older link has been used.

Snapshot a ready site's database and files, then launch fresh sandboxes from that saved configuration.

Restore a saved template into a new disposable WordPress site without rebuilding the setup by hand.

Give anyone a link that creates a temporary copy of a template, with no SandyWP account required.

Configure a share link to use either the visitor's allowance or the template owner's plan quota.

Require an email before demo creation and review collected leads from the template's Share panel.

Brand a launch page with a logo, colors, background, headline, supporting copy, CTA text, and optional white-label presentation.

Select multiple sites in the dashboard and remove them in one action.

Upload plugins, themes, and media files without the old PHP default size limit getting in the way.

Compare and select an upgrade plan in SandyWP, then continue to secure checkout.

Open the Polar customer portal to manage subscriptions, invoices, and payment methods.

SandyWP refreshes subscription entitlements when users return from checkout, including through login or signup redirects.

New sites receive the lifetime chosen in the creation form.

Version-specific sandboxes verify that installed WordPress core matches the requested release.

Signed-in users can choose WordPress and PHP versions directly from the homepage creation flow.

Paid-plan users can turn an active temporary sandbox into a permanent one, or return it to temporary status later.

Guest sites now expire after seven hours, while account-owned sites use their selected lifetime.

Set a password for a Google-created account or change an existing password from SandyWP account settings.

Choose and save an avatar preset for your SandyWP profile.

Select how long a signed-in sandbox should remain available, from one hour through one month.

WordPress 7.0 and 6.9 join the selectable version list.

Automatic core updates are disabled so version-specific test sites stay on the selected release.

See each sandbox's calculated storage size directly in the site list.

Storage allowances are enforced by plan, with a clear upgrade path when more space is needed.

Prepared WordPress sites can be claimed almost immediately, with credentials generated ahead of time.

Create a debugging-ready site with WP_DEBUG options and optional Query Monitor installation.

Select an available SandyWP worker region when creating a site.

Create or access an account using Google alongside email and password.

Request a secure reset link when an email and password account needs a new password.

Paid subscriptions are available through secure Polar checkout, with plan limits applied to SandyWP accounts.

Start an upgrade directly from the public pricing experience and return to SandyWP after purchase.

A redesigned create-site and progress experience keeps stack settings, provisioning status, and the next action easy to follow.

Open, sign in to, and clean up sandboxes from one accessible action menu.

Explore SandyWP's capabilities and plan options before creating a site.

Create a temporary WordPress site as a guest or from an account, with a public URL and automatic expiration.

Launch the latest WordPress or a pinned version on PHP 8.3, 8.2, or 8.1.

Open a ready site's WordPress dashboard through a secure automatic-login link.

Signed-in users can see their sites, provisioning status, expiration, and remove sites when finished.