Requirements and hosting

Supported environments

The floor: 30 seconds and 128 MB

Shared hosting commonly gives a PHP request thirty seconds and 128 MB, and stops it when either runs out. The worker is written for that floor:

• A backup is a sequence of steps, each small enough to finish inside the limit, each recorded before the next begins. If a step is cut off, the next call continues from the last recorded one. The pieces are read back before the backup is called complete.
• A restore, and a download from external storage, work the same way, one piece at a time.
• An update round is driven from the platform one operation at a time: back up the plugins, update one, verify, on to the next.
• The site calls the platform on WP-Cron, and the work it picks up there is stepped on WP-Cron too.

More execution time and memory make all of it faster; none of it depends on more.

What WP-Cron means here

WordPress's scheduler runs when a page is requested. The worker uses it for the parts of its work that happen between calls from the platform: continuing a backup, running a scheduled one, pruning old ones, reporting to the platform. On a busy site that is effectively continuous; on a quiet one it runs when a visitor or the platform arrives. A site with DISABLE_WP_CRON and no system cron in its place does that work only when something calls it. The platform shows the age of each dataset rather than guessing, so such a site is visible as one whose data is older than it should be.

Storage on the site

Backups the site makes are written under wp-content/backups/, in a directory whose name carries a secret of the site's own, one folder per backup. The size of a full backup is roughly the size of the site. A storage policy of external has the platform release the site's copy once the copy in object storage is verified, so the site holds a backup only for as long as the upload takes. The activity and email logs are daily files in the same area; the error log and analytics are tables of the plugin's own.

Outbound HTTPS is the one hard dependency

The site must be able to open an HTTPS connection to the platform. That is what registration, reporting, picking up work and update checks all use, and it is the one channel that survives a host firewall blocking the platform's calls. A site that cannot make outbound HTTPS calls at all — a rare host setting — can be managed only when the platform can reach it, and then only from the platform's side.

Limits that come from the host

• A firewall or bot protection in front of the site may refuse the platform's calls. The site keeps working on its own schedule; see Hosting compatibility.
• A page cache that caches the WordPress REST API is told not to on the worker's answers; see Connection.
• A host that strips the Authorization header is handled by the worker's own header since 2.3.0.
• A host that blocks outbound connections to anything but a list of addresses needs wpocto.com on that list.