Sandboxes: test upgrades and AI agents on a copy of your apps

An isolated copy of an app and its data, inside your perimeter, where upgrades, agents and experiments run before they touch production.

Start with one workloadBook a 30-minute briefing

Contains
The app, its configuration and a copy of its data
Runs
On your machines or your dedicated Pilae Cloud machines
Network
Private mesh only, never published through the gate
Lifetime
Set when it is created, removed and recorded at the end

Try it on the copy, not on the business

A staging server that drifted from production six months ago proves very little. A sandbox is cut from production when you need it, so the upgrade, the new workflow or the AI agent meets the same version, the same configuration and the same data.

A real copy, on demand

The sandbox is built from the latest verified backup of the app: same version, same configuration, same data. Nothing is mocked.

Inside your perimeter

It runs on the same machines or in the same country as production. The data in it never leaves the environment it came from.

Isolated from production

Its own database, its own storage, its own network segment on the private mesh. Outbound email and webhooks are held back unless you allow them.

Upgrades rehearsed first

The Pilae Agent runs a major upgrade or a migration in a sandbox before it writes the production plan, and attaches the result to that plan.

A safe place for agents

Let an AI agent or an MCP client act on real data with write access, and read what it did, before you grant the same access in production.

Gone when you are done

Each sandbox has an expiry date. At the end it is destroyed with its data, and the creation, access and removal are kept in the audit trail.

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.

How a sandbox runs

  1. Request

    You, your team or the Pilae Agent asks for a sandbox of an app from the console, with a reason and an expiry date.

  2. Approve

    The request follows your approval rules, like any other change. Sandboxes of apps holding sensitive data can require a named approver.

  3. Build

    The sandbox is restored from the latest verified backup onto capacity inside your perimeter and joined to its own segment of the private mesh.

  4. Use

    Run the upgrade, the agent or the experiment. Access is limited to the people and tools you name, and each session is recorded.

  5. Remove

    On expiry or on request, the sandbox and its data are destroyed. The console keeps the record of what ran and what came of it.

What your contract includes

Rehearsed upgrades
Major upgrades and migrations of the apps we operate are run in a sandbox before the production plan is proposed.
Data location
Sandboxes stay on the machines or in the country agreed for production, under the same DPA.
Access
Named people and tools only, over the private mesh, with every session in the audit trail.
Removal
Each sandbox is destroyed at its expiry date, and the removal is recorded in the console.

The apps behind it

Questions

What is an app sandbox?

A temporary, isolated copy of one of your apps with its configuration and data, built from a verified backup. You use it to test an upgrade, a new workflow or an AI agent before the same change reaches production.

Does the data in a sandbox leave our environment?

No. A sandbox runs on your own machines or on your dedicated machines in Pilae Cloud, in the same country as production. It is covered by the same DPA and the same access rules as the app it was copied from.

Can a sandbox send email or call other systems?

Not by default. Outbound email, webhooks and integrations are held back so a test does not reach real customers or real systems. You can allow specific connections when a test needs them.

Can we test AI agents with write access in a sandbox?

Yes. That is one of the main reasons to use one. An agent or MCP client can create, edit and delete records in the sandbox, and every call is logged, so you can decide what access it should have in production.

How long does a sandbox last?

As long as you set when you create it. When it expires, the sandbox and its data are destroyed and the removal is recorded. You can extend it before then.

Related

Rehearse your next upgrade on a copy.

Thirty minutes with an engineer: we walk through a sandbox of one of your apps and the upgrade plan that comes out of it.