Back to the blog »
Here the elsewhere ridiculed multisite quietly earns its keep: the clone lands on the same codebase as the original, so when all you are testing is database work or a theme, the sandbox costs you no second platform at all. When you are testing bigger things, you clone more than once – one copy stays on the live codebase as your fallback, others get Migrated onto an updated codebase, and suddenly you have development, testing and staging without inventing any of it. And a test codebase is yours to update in place, Composer and all; some brave souls run composer upgrades in place on the live codebase too, once things look green on the test one; we do not recommend it, but neither do we block it, risky routes are yours to take.
Notice what is missing in all of this: an enforced workflow. These are capabilities, and you compose your own flavour from them – one careful sandbox, a whole dev-test-stage ladder, or something nobody else would approve of, the machine follows your lead either way. The defaults simply keep the recommended road paved and lit: the safe route is the easy one, never the only one.
Yet nothing about it is second class: to the rest of the stack your sandbox is a site like any other, so it gets the same nightly backups and sits behind the same edge protections as production, because the machinery simply does not know the phrase ‘just a test copy’.
You know the ritual, or you knew it once: dump the database, rsync the files, patch settings.php, invent a vhost, and then the quiet fear which never realy leaves – was there a cache table you missed, is the copy still pointing at the live database, and what will its cron decide to do to real data at 3am. And if you moved all of that onto one of the big managed platforms years ago, you know the other side of the deal instead: dev copies are a button there, true, but they live inside somebody else’s walls, on somebody else’s meter, and only for as long as the subscription does.
And the copy is honestly yours to break: its files/ and private/ are real copies in its own store, so a cleanup gone wrong in the sandbox eats nothing in production, which is more than can be said for many hand-made copies quietly sharing an uploads directory with their origin (we have all seen that one end badly).
Then comes the part where the sandbox starts working for you. Naming matters first: call the copy dev.something or test.something and it is counted as what it is (a dev site, not another production site, with its own larger SQL limits on hosted plans), and the stack quietly bounces self-identifying crawlers off it too, so it stays out of the index. The dev-mode switch is a separate trick, and its whole point is that it works on aliases only – which means you can use it on a live production site. Give any site a dev.-prefixed alias, and on that hostname alone it flips into dev behaviour: PHP errors on screen, opcache revalidating on every request so code edits show instantly, the hardcoded performance settings released so caching and aggregation can be toggled from the UI – while on its production name the very same site keeps serving visitors exactly as before. Debugging production without touching production, no clone required. Full honesty: these PHP-side switches speak Drupal today, not yet Backdrop (everything above them, handbrake included, is identical for both), and closing that gap is simply the direction we keep walking.
When the experiment is over, the sandbox goes one of two ways. Most get deleted with a clear conscience, and you clone a fresh one next time, clones are disposable here by design. The one which grows up so well that it deserves to take over gets promoted instead: a Migrate rename onto the live name, once that name is freed – the panel refuses to steal a domain from a living site, which is exactly the kind of refusal you want from your hosting. And once the sandbox has proven a change, how does it reach the live site without the Friday-evening sweat? That is another chore the machine considers its own, because behind this one sits machinery which runs the entire life of a site, from first install to retirement. The sandbox half, with the recovery scenarios we skipped today, is covered wall to wall in the cloning guide – careful, though, the neighbouring chapters have a way of eating an afternoon of their own.
Do you test risky changes on a copy of your site, or on the live one, with one eye closed and a backup from last Tuesday? Or maybe you skip the sandbox altogether, because building one is exactly the afternoon you do not have? Making a safe copy of a living site is the classic of the chores which never made it into anyone’s job description: everyone agrees a sandbox should exist, volunteering to build one is another matter.
A sandbox is also allowed to be picky about its visitors. Per-site allow-lists take IPv4 and IPv6 with CIDR ranges, for the whole site or scoped to just /user and /admin, and HTTP auth sits at the vhost layer with the right carve-outs, so a password-protected copy still renews its certificate and answers its cron pings once you switch those back on. None of it goes anywhere near the firewall, it is all vhost-level, so an over-eager allow-list can never cost you the server.
Now the part which makes it a proper sandbox and not merely a copy. A fresh clone arrives the way a careful garage hands your car back – with the handbrake pulled. Scheduled cron is off, deliberately: a copy which behaves exactly like production will sooner or later do something to real data you cannot undo, and the classic is a forgotten test copy quietly mailing real customers three weeks later. HTTPS lands off as well, for its own reason: the certificate is bound to the source site’s name, so it is never carried over. Enable Encryption on the copy and it gets its own. Until then the copy sits fully alive yet going nowhere, and you let the handbrake off yourself, when you mean to.
On a BOA server the whole ritual is one Ægir task: Clone. Name the copy, run the task, and the machinery first takes a fresh backup of the original (the clone is cut from that backup, not scraped from the live tree, so expect a big site to take a while longer), and then you get a genuinely independent copy: its own database, its own vhost, the site’s files copied into a per-site store of their own. DNS for the new name stays your job, as ever; /etc/hosts does fine for a sandbox meant for your eyes only. Same task, same way, from Drupal 6 to Drupal 11 and Backdrop alike – and if the dev-environment button on a managed platform is your reference point, this is that button, running on a server which answers to you.
