Choose a lifetime
Keep a site permanent or set it to expire after 1, 3, 7 or 30 days. An hourly service destroys expired containers, data and routes; the cockpit lets you extend a site or make it permanent first.
Free · Open source · Self-hosted
Run your own WordPress sandbox.
SpawnWP turns a fresh Debian or Ubuntu server into a remote lab for disposable, isolated WordPress environments — with a web cockpit, controlled lifetimes and no hosted control plane.
What a sandbox is
A place where breaking WordPress is part of the job.
A WordPress sandbox is an environment created for experimentation rather than production traffic. You can install code, change configuration, reproduce a bug or test an update without making a shared site the single fragile place where every experiment happens.
SpawnWP gives each site its own Nginx, PHP-FPM, MariaDB, Mailpit and Adminer stack. When the task is complete, reset the site, restore a snapshot or destroy the environment and its routes.
Sandbox controls
Disposable when you want. Persistent when you need.
Start from a blueprint
Use Development, Clean or Demo, add an administrator-authored manifest, or capture a configured WordPress site as a reusable blueprint on your server.
Switch PHP deliberately
Create or switch sites across PHP 7.4, 8.2, 8.3 and 8.4. PHP 7.4 is present only for legacy compatibility work, not as a recommended runtime.
Inspect without sending
Mailpit captures outgoing WordPress email, Adminer exposes the isolated database behind cockpit authentication, and the development blueprint includes QA and debugging tools.
Under the hood
Isolation is enforced per site, not assumed.
Dropped capabilities by default
Every container starts with cap_drop: [ALL], then only the specific Linux capabilities that one service needs are added back — PHP-FPM gets CHOWN/SETUID/SETGID/DAC_OVERRIDE, Nginx gets CHOWN/SETUID/SETGID/NET_BIND_SERVICE, nothing gets more than it requires.
No privilege escalation
security_opt: no-new-privileges is set on every service, so a compromised process inside one site's container cannot escalate privileges even if a setuid binary is reachable.
Hard resource ceilings
Each site's containers carry explicit CPU and memory limits. A runaway plugin or a misbehaving script in one sandbox cannot starve the others sharing the same server.
Separate stacks, separate networks
Nginx, PHP-FPM, MariaDB, Mailpit and Adminer are dedicated per site rather than shared multi-tenant services, each on its own Docker network — one site's database is not reachable from another site's containers.
Different environments, different promises
Sandbox, staging or local development?
| Environment | Best for | Connection to production | Where it runs |
|---|---|---|---|
| SpawnWP sandbox | Disposable development, compatibility tests, demos and bug reproduction | Independent; publishing is your choice | Your remote server |
| Staging | Validating a specific production release and deployment path | Usually mirrors or feeds production | Often beside production hosting |
| Local development | Offline work with minimal infrastructure | Independent until pushed or exported | A developer's computer |
Read the complete sandbox vs staging guide →
Choosing a product rather than an environment type? Compare SpawnWP with InstaWP's managed cloud, Local's desktop workflow or TasteWP's temporary hosted sites.
Who this is for
Built for people who break WordPress on purpose.
Plugin and theme developers testing across PHP versions before a release. Agencies reproducing a client bug without touching the live site. QA work ahead of a WordPress core update. Anyone who needs a real WordPress install rather than a client-side emulation.
What you provide
A fresh server, two hostnames and administration.
SpawnWP supports Ubuntu 22.04, 24.04 and 26.04 or Debian 12 and 13 on amd64 and arm64. It expects root or sudo access, ports 80/443, and two DNS names already pointing to the machine.
Common questions
Before you build the lab.
Is SpawnWP a staging service?
No. It creates isolated development, testing and demo environments. It does not continuously synchronize a production site.
Can a SpawnWP sandbox stay online?
Yes. Sites are permanent by default, or you can choose a lifetime of 1, 3, 7 or 30 days.
Does SpawnWP run on a laptop?
SpawnWP targets a fresh Debian or Ubuntu server with two hostnames. It is remotely accessible rather than a desktop application.
Is this a free WordPress sandbox with no signup?
Yes, in the self-hosted sense: SpawnWP is free, MIT-licensed software with no vendor account, signup or plan. You install it on your own server and only that server has a cost.
Do sandbox sites have a time limit?
Only if you want one. Sites are permanent by default; you can optionally give a site a 1, 3, 7 or 30-day lifetime and it destroys itself when it expires. No plan-imposed expiration.
Is each sandbox actually isolated from the others?
Yes. Every site gets its own Nginx, PHP-FPM, MariaDB, Mailpit and Adminer containers, each with capabilities dropped by default, no-new-privileges enabled and explicit CPU/memory limits — not a shared multi-tenant stack.
One server, many clean starts
Build the sandbox infrastructure you control.
Review the requirements, point two hostnames and let the installer configure the lab.