Supported and Unsupported 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

All supported hosts have been tested by an official SolidWP team member and are verified to work with Solid Backups — NextGen

✅ Bluehost

✅ NameCheap

✅ SiteGround Shared

✅ Hostinger

✅ Nexcess

✅ Liquid Web VPS w/ CPanel

✅ Liquid Web VPS w/ InterWorx

✅ Dreamhost

✅ GoDaddy Managed

✅ GoDaddy Shared

✅ SpinupWP (DigitalOcean)

✅ Generic VPS (Ubuntu/Ngnix)

✅ A2 Hosting

✅ Kinsta

✅ IONOS

✅ MochaHost

✅ LearnDash Cloud

✅ Vultr

✅ Cloudways* (see addendum)

 

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 us collect data that we can report to the hosting provider to hopefully incentivise a way to resolve the connection with them. 

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.

❌ Pressable (Request support for Pressable)

❌ WP Engine/Flywheel (Request support for WPE/Flywheel)

❌ Pantheon (Request support for Pantheon)

❌ WPX ( LiteSpeed server) - Unable to Support

❌ WordPress.com - Unable to support

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

Hi there!

I am interested in using Solid Backups — NextGen to back up my site, but according to this article, connecting via SSH at the level necessary to do that is not supported. Please consider allowing me to connect my site to this simple cloud-based backup solution. 

 

Addendum: Cloudways support 

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.

Have more questions? Submit a request