Getting the site out
is the hard part.

Most staging tools fall over on the same sites: the 12 GB shop on shared hosting with a 30-second execution limit and no shell. The backup runs in slices that each finish inside the host's limits and pick up where the last one stopped, so size stops being the thing that decides whether this works.

✓ Survives execution limits ✓ Straight to storage ✓ Verified by actually booting
Backup specIn place
DatabaseChunked SQL dump
Fast pathmysqldump when available
FilesZIP, resumable
Splits above1.8 GB per part
Large uploadsMultipart above 50 MB
TransferPresigned, direct to storage
PathNever through our servers
Quick mode above2 GB
Take-home archiveDB + wp-content
HostingEU

A backup that stops
halfway is not a backup.

Shared hosts kill long-running requests, cap memory, and often forbid shell access. The connector works inside those limits rather than against them: the dump and the archive advance in slices that each finish well inside the host's execution window, recording where they stopped. Our platform drives the next slice, so nothing depends on the site's own cron being healthy. Where the host does allow it, mysqldump and the zip binary are used instead — checked with a five-point probe first, not assumed.

Three things that break
at scale, handled.

01 · Archive size

Splits at 1.8 GB

Past that, the files archive is written as numbered parts instead of one file that no PHP process on a shared host could assemble. The staging pulls every part in order.

02 · Upload

Multipart above 50 MB

Anything larger streams to storage in parts, so a dropped connection costs one part rather than the whole transfer. The bytes go from your server to storage directly.

03 · Media libraries

Quick mode above 2 GB

Uploads are skipped and the staging redirects missing images to your live site instead. You are testing an update, not the photographs — and the decision is written into your activity log with the numbers behind it.

Green means it booted.

A staging is not reported ready when the files finish copying. It is reported ready when the restored site answers a real request over its public URL. A backup that cannot be restored therefore never becomes a green checkmark — the launch fails instead, with the restore steps in the activity log showing where it stopped.

This is also why we do not sell a nightly restore drill: every launch already is one. There is no archive sitting untouched for months waiting to be discovered broken, because backups exist to become a staging and are swept once it ends.

Then take it home.

When the staging looks right, download the database and wp-content as one archive and roll it out yourself. We do not push to your production site — that call stays yours.

Start free All features →