Supported And Unsupported Web Hosts

Introduction #

Solid Backups — NextGen is a cloud-based system for backing up WordPress websites that utilizes SolidWP server infrastructure instead of taxing your hosting environment’s resources. Because it’s designed to be host-agnostic, once your site is connected you’re all set.

The power of WordPress as free software means that it’s able to be installed on a wide variety of web hosts, both in terms of quality of hosting (reliability, support, etc) and in terms of geographic distribution. That comes with a large burden for products attempting to interact with WordPress websites (especially at the level that Solid Backups — NextGen does!).

The SolidWP team has tested (and will continue to test) widely to ensure compatibility with the largest number of hosts possible. 

The list below displays every hosting provider on which Solid Backups — NextGen has been tested. It will help determine if your hosting provider supports a Solid Backups — NextGen connection.

If you don’t see your hosting provider, this doesn’t mean Solid Backups — NextGen won’t work with it; only that it has yet to be tested. Most hosting providers will support Solid Backups — NextGen, if you run into any issues with an unlisted Hosting provider reach out to SolidWP Customer Support.

Supported Hosts #

Unsupported Hosts #

This is every host known to have connection issues when using Solid Backups — NextGen.
If you find your hosting provider on this list, follow the feedback link next to the host name and give the issue an upvote. This upvote will help the SolidWP team collect data in prioritizing a solution. 

In many cases the reason that a host is unsupported falls outside the scope of something the SolidWP team can control, so you might also reach out to your host with a request to enable support for Solid Backups — NextGen.

Here’s a sample message you can send to your web host requesting support for Solid Backups — NextGen

For Solid Backups — NextGen to work on Cloudways hosting, you’ll need to find the line in the wp-config.php file that looks like this:

require('wp-salt.php');

…and replace it with this:

require __DIR__ . '/wp-salt.php';

Here’s a brief explanation of what that’s doing and why it matters:

In testing for Cloudways hosting compatibility, the SolidWP team discovered that by default Cloudways moves the normal security salts typically found in wp-config.php into their own file named wp-salts.php, and then calls for those salts using the require(‘wp-salt.php’); line.

This is fine and perfectly secure. When WP-CLI (the command line interface that Solid Backups — NextGen and many others use to interact with WordPress) is called, it uses that wp-config.php file as a starting reference point.

That’s all well and good until a system like Solid Backups — NextGen attempts to use WP-CLI remotely, and then the fact that the line referencing wp-salt.php isn’t quite specific enough, so WP-CLI itself gets confused and bails out, causing problems. The change to include __DIR__ in the reference to wp-salt.php helps to clarify for the script exactly where to find that file, which prevents WP-CLI from tripping up. 

In case you’re wondering, modifying that line in wp-config.php should not have any other effect, since it’s just adding more specificity to the call for wp-salt.php.

How about hosts with non-standard WP-CLI setups? #

In Plesk/WP-Toolkit environments, the WP-CLI command is managed via Plesk’s WP Toolkit internals rather than a system-wide wp binary. This causes failure when Solid Backups — NextGen attempts to run CLI commands for license checks, backups, or site management. 

An example of a failed command looks like this, which indicates that wp is invoking a Plesk WP-Toolkit–specific command which is missing.

Failed to open stream: No such file or directory in /usr/local/bin/wp
require_once(/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wpt-wp-cli.php)

Because of this, NextGen cannot verify your license via the wp ithemes-licensing show solid-backups command, leading to a “bad_license_key / license_check_failed” error.

If you or your hosting provider have control over the Plesk server, the following steps might help make NextGen functional:

1. Install WP-CLI globally so that a wp command is available system-wide.
2. Ensure the global wp is symlinked or accessible to the Plesk-managed domain environment.
3. Add or configure SSH access for a user that has permission to run WP-CLI within that Plesk-managed site.
4. Adjust file permissions so the wp binary and associated files are readable/executable by the site’s user.
5. Provide your host with the CLI commands NextGen expects (e.g. wp ithemes-licensing show solid-backups) so they can test in your environment.

Known caveats

• This workaround is not yet fully validated across all Plesk setups.
• Some users report being able to work around it by ensuring a global wp binary or adjusting permissions, but these solutions depend heavily on host configuration and the Plesk WP Toolkit version.