Sitecarry builds a single package containing your site’s files and a full database
export, then lets you download it from the WordPress admin.
Watch the four-minute tutorial: back up, send to Google Drive, prove the backup restores, restore and move a site.
The build runs in short, resumable slices, so it works on shared hosting where a
single PHP request is capped at 30 seconds. If a request times out, the next one
picks up exactly where the last one stopped.
Each package comes with a standalone installer that restores it onto any server —
the same file works for moving a site to new hosting, cloning live to staging, or
rolling a site back.
What it does
- Full site package: files plus a complete SQL export
- Your
wp-config.phpis never archived, so the database password and the login
keys and salts stay on the server; the restore writes that file itself - Scheduled backups — hourly, twice daily, daily or weekly, with retention
- Optional incremental file backups, with automatic full backups in between
- Upload to Amazon S3, any S3-compatible storage, FTP or Google Drive — Drive
connects in one click, or with a Google app of your own if you would rather keep
the plugin’s author out of it entirely - Restore straight from storage when the archives are no longer on the server
- Email or Slack/Discord notification when a backup fails. The email names every
detail of your newest backups — where they are, their checksum and, if you allow
it, the restore passphrase — so you have them even if the site will not open - Verify that a package is intact, from the admin or WP-CLI
- Rehearse a backup, by hand or every week — import it into scratch tables, check
the row count, prove the result would work as a site, and
confirm serialized data survives a domain change. Then throw the tables away.
Nothing on the site is touched - WP-CLI commands for backing up, listing, verifying and checking status
- Backups run in the background — start one and close the tab
- Resumable build and resumable restore — both survive short PHP execution limits
- Live progress throughout
- Restore this site with one button — the package’s database is rebuilt in
tables of its own, swapped in atomically, and the files put back afterwards - Restores from a package that is only in storage: Sitecarry downloads it back
from Google Drive, S3 or FTP first, resuming if the request runs out of time - Migration links — move a site to another server without downloading and
uploading a gigabyte by hand: create a link on the old site, paste it into the
installer on the new one, and the package travels straight between the two servers - Standalone
installer.phpfor moving a site to a different server, where there is
no WordPress to press a button in - Serialization-safe URL rewriting, so page builder content survives the move
- Skips caches,
node_modules,.git, and other backup plugins’ folders, which is
usually the difference between a 400MB package and a 40GB one - Records a manifest describing the origin site (URLs, table prefix, versions)
Why URL rewriting is the hard part
WordPress stores a lot of settings as PHP serialized data, where every string
carries its own byte length. Replacing an old domain with a longer one using a
plain search and replace breaks those lengths, and WordPress can then no longer
read the value — which is how a migration quietly wipes widget settings and page
builder layouts. Sitecarry rewrites the serialized form directly and repairs the
lengths, and it also handles the JSON-escaped form (https:\/\/) that page
builders such as Elementor store their content in.
Security
Packages contain a complete copy of your database. Sitecarry stores them in a
protected folder with an unguessable filename, blocks direct web access via
.htaccess and web.config, and serves downloads only through an authenticated
admin request — never a public URL.
Every package has its own restore passphrase, shown in the admin and kept out of
the archive. The installer refuses to do anything without it, so an installer
left behind on a server cannot be used by anyone else to overwrite the site. It
also deletes itself and the archive when the restore finishes.
Bundled fonts
The admin screens use Manrope and JetBrains Mono, both under the SIL Open Font
License 1.1. They are shipped inside the plugin, in assets/fonts, and nothing is
loaded from Google or any other host to draw them.
External services
Out of the box Sitecarry talks to nothing but your own server. It contacts an
outside service only when you switch one on, and only with what that service needs
to do its job. It never sends usage data, analytics or licence checks anywhere.
Amazon S3, or any S3-compatible storage — used only when you set Storage to S3.
Sitecarry sends your backup archives, and the requests needed to list and delete
them, to the endpoint you enter (by default https://s3.<region>.amazonaws.com, or
your own for Backblaze B2, Wasabi, DigitalOcean Spaces, MinIO and so on). What is
sent: the archive itself — which contains your site’s files and a full database
export — plus the access key you configured, used to sign each request. Nothing is
sent until you save S3 credentials and run a backup.
For any other S3-compatible provider, the terms are that provider’s own.
- Service: Amazon S3, provided by Amazon Web Services (
amazonaws.com) - Terms of service: https://aws.amazon.com/service-terms/
- Privacy policy: https://aws.amazon.com/privacy/
FTP / FTPS server — used only when you set Storage to FTP. Sitecarry connects to
the host, port and path you enter and uploads the same archives, authenticating with
the username and password you configured. The server is one you choose, so its terms
are your host’s. Plain FTP sends that password and the whole archive unencrypted;
the settings screen recommends FTP over TLS for this reason.
Google Drive — used only when you set Storage to Google Drive and complete the
connection. Sitecarry sends you to https://accounts.google.com to authorise,
exchanges the code at https://oauth2.googleapis.com/token, and uploads, lists and
deletes archives through https://www.googleapis.com/drive/v3 and
https://www.googleapis.com/upload/drive/v3. What is sent: the archives, and an
OAuth token belonging to the Google account you authorise. The connection uses an
OAuth client you create yourself, so the traffic is between your site and Google —
it is not routed through us. Only the drive.file scope is requested, which limits
Sitecarry to files it created itself.
- Service: Google Drive API, provided by Google (
googleapis.com,accounts.google.com) - Terms of service: https://policies.google.com/terms and https://developers.google.com/terms
- Privacy policy: https://policies.google.com/privacy
dotance.com — only if you choose “Connect with Google” — Google Drive needs an
OAuth app, and this is the one Sitecarry lends you so connecting takes a click
instead of ten minutes in the Google console. When you press that button your
browser goes to https://dotance.com/wp-json/dotance/v1/google/start, on to
Google’s own consent screen, and back; your site then collects the resulting
permission from .../google/claim, and asks .../google/token for a fresh
access token about once an hour while a backup runs. What is sent: your site’s
address, and the permission Google issued for the Drive you approved. What is
never sent: your backups — they upload from your server straight to Google — and
no credentials of any other kind. Choose “Use my own Google app” instead and
nothing touches dotance.com at all.
- Service: Dotance (
dotance.com), the plugin’s author - Terms of service: https://dotance.com/terms/
- Privacy policy: https://dotance.com/privacy-policy/
Slack, Discord, or any incoming webhook — used only when you enter a webhook URL
on the Notifications screen. Sitecarry posts a short message to that URL when a
backup finishes or fails: the site name, the outcome, the step it stopped on and the
error text. No archive and no credentials are sent. The destination is the URL you
supply, commonly https://hooks.slack.com/....
- Service: Slack incoming webhooks (
hooks.slack.com) - Terms of service: https://slack.com/terms-of-service
- Privacy policy: https://slack.com/trust/privacy/privacy-policy
- Service: Discord webhooks (
discord.com) - Terms of service: https://discord.com/terms
- Privacy policy: https://discord.com/privacy
Another site, by migration link — used only when you open Restore, choose
Migration link, and paste a link and key that someone gave you (or that you made on
your other site). Sitecarry then sends HTTP requests to the address in that link,
which is a site you name, normally another site running Sitecarry: one request for the
description of the package, then requests for the archive in pieces. What is sent: the
link’s token, which is already part of the address, and a signature made with the
package’s restore passphrase. The passphrase itself is never sent. What comes back is
the package, which holds that site’s files and a full database export, and is saved in
wp-content/uploads/sitecarry/. Requests go through WordPress’s safe HTTP function, so
addresses on a private network are refused. Nothing is sent until you press Check
link. The downloadable installer does the same when you paste a link into it. The
terms are those of the site you name. On the site that made the link, Sitecarry only
answers requests that carry both the token and a valid signature, and contacts no one
itself.
Your own site — Sitecarry sends an HTTP request to your site’s own
admin-ajax.php to start and continue a background backup. That is a loopback
request to your server, not a third party.
Screenshots
Whether the site is protected right now, in one line, with every package, whether it has been proven to restore, where its copy lives, and what has happened over the past month.
When backups run, how many are kept, the weekly rehearsal that proves the newest one still restores, and what goes into a package.
Sending finished packages to Google Drive, Amazon S3, anything that speaks the same protocol, or FTP, with the copies already sent away listed beside it.
Being told when a backup fails, by email or into Slack or Discord, and a preview of what the email says.
Restore this site: what will be replaced, a safety backup of the site as it is now, and the checks made before anything changes.
The notification email: your newest backups with where each is stored, its checksum and the restore passphrase, so the details are in your inbox even if the site will not open.
Moving a site without downloading anything: a migration link and its key, to send by different routes. The link works once, expires, and can be revoked.
The installer on the new server: paste the migration link and the backup comes straight from the old site, with nothing downloaded to your computer first.
The Restore tab: bring a package in by uploading the zip, pasting a migration link, or picking one already on the server. No installer needed.
The key and what Sitecarry found: where the package came from, its size, whether the key is right, and the checks made against this site before anything changes.
The confirmation: a backup of the site first, the old site's address changed to this one's, and the sign-out that follows because the users are the old site's.