Why a copy beats a staging server
Most teams have a staging environment. Few trust it. It runs an older version, holds data from last year and was configured by someone who has since left. A test that passes there says little about production.
A sandbox is cut from production when you need it, from the latest verified backup. It has the version, the configuration and the data your users work with today. When the test is over, it is removed, so there is nothing left to drift.
Where the Pilae Agent does its rehearsals
Before the Pilae Agent proposes a major upgrade or a migration, it runs the change in a sandbox and attaches the outcome to the plan: which steps ran, how long they took, and what the app looked like afterwards. You approve a change that has already worked once on your data.
The same applies to your own agents. If you want an assistant to act on your apps through MCP servers, give it a sandbox first. Read the audit trail of what it did, then decide what it may do in production.
Inside the perimeter, under the same rules
A sandbox is not a way around your data rules. It runs on your premises or on your dedicated machines in Pilae Cloud, in the same country as production, on the private mesh. Its creation, every session and its removal appear in the control plane next to the rest of your estate. What each plan includes is on our pricing page.