We earn commissions when you shop through the links below.
Cloudways
One Cloudways server. One job per app.
Cloudways gives you real SSH under the managed layer. VPS Snaps finds every app and gives each its own file and database job — so one site restores without touching the rest.
Scan server
Looks for WordPress, Laravel, Craft CMS, and Ghost installs in common web-root locations. Database credentials are read automatically where the config format allows it.
Storage destination for created jobs
www/acme-blog
/var/www/acme-blog
File backupDatabase backup (acme_blog)
www/acme-app
/var/www/acme-app
File backupDatabase backup (acme_app)
sites/acme-docs
/home/deploy/sites/acme-docs
File backupDatabase backup (ghost_prod)
There is no Cloudways integration to authorise
No API token field, no OAuth screen, no app to approve inside your Cloudways account. A Cloudways server is added the same way a bare Hetzner box is — host, port, username, key.
That is not a gap we are working around. The two things you actually want back after a bad deploy are an application’s document root and its database, and both of those live on the filesystem and in MySQL on the server itself. An SSH session reaches both directly. A platform API sits above them, speaking in whole servers and its own storage, and would have to be translated back down to the same two things anyway.
Going straight at the machine is what makes the rest of this page possible: per-application granularity rather than per-server, artifacts written into a bucket you own in formats you can open without us, and a connection you revoke by deleting one public key from a page you already have open. Move the site off Cloudways onto a plain VPS later and you change the host on the server record — the jobs, the schedules and the history carry on.
The Cloudways layout is already one of the six web roots the scanner knows, so nothing about a Cloudways box needs a special mode. The roots are shell globs expanded by your own shell: a pattern matching nothing contributes nothing, which is why the Forge and plain-/var/www patterns in the same list cost you nothing here.
Not on Cloudways yet? It is managed hosting that still gives you real SSH, which is what makes everything on this page possible.
Try CloudwaysAffiliate link — we earn a commission if you sign up.
What the connection needs
- The server's public IP address
- The SSH username — the master user Cloudways shows you
- Port 22, unless you have moved it
- An SSH key pair, or a password if you prefer
What it never asks for
- Your Cloudways account login
- A Cloudways platform API token
- A plugin installed inside WordPress
- A daemon or agent running on the server
The one step that is genuinely Cloudways-specific
Everything else on this page is the same on any server. This part is not, and it is the reason most first attempts fail.
On a normal VPS you would run ssh-copy-id and be done. On Cloudways the platform owns the master user’s authorized_keys file and rewrites it. A key appended by hand can work fine today and be gone the next time Cloudways regenerates that file — at which point your backups start failing on authentication, at 02:00, with nothing else having changed.
Register the key through the dashboard instead and it survives, because you are telling the thing that owns the file rather than arguing with it.
Do not edit authorized_keys
Add the public key here instead:
Cloudways dashboard → your server → Master Credentials → SSH Keys
The public IP and the SSH username are printed on that same Master Credentials page. Copy all three while you are there and you will not have to come back.
From pasted key to running jobs
Five steps, most of them one click. The only typing is an IP address and a username.
Paste the public key into Master Credentials
Generate a key pair in VPS Snaps under Settings, or bring your own. Only the public half is ever shown to you to copy; the private half is sealed with AES-256-GCM before it is written to our database, and is only decrypted inside the worker at the moment a run starts.
Add the server with the IP from that same page
Servers → Add server. Host, port, username, and the key you just registered. Run the connection test before you go further — an authentication problem is much easier to read here than at 02:00 in a run log.
Click Detect applications on the server
This opens a read-only SSH session and runs a single find across six web-root conventions. The Cloudways one is in that list, so a Cloudways box needs no special mode — the pattern matches, and the other five contribute nothing.
The root that matches on Cloudways
/home/master/applications/*/public_htmlPick a storage destination, then create jobs per app
Each app you accept produces a file backup job for its directory, plus a database backup job when its config file surrendered a usable database name. Both are created enabled, on a daily schedule at 02:00 UTC, with 7-day retention, failure alerts on and success alerts off. Every one of those is editable afterwards.
Rename the jobs before you have twelve of them
Job names are built from the last two segments of the detected path. On a hand-rolled server that reads www/acme-blog. On Cloudways it reads something like gzxkmpqvwd/public_html, because Cloudways names application directories with an opaque ID rather than the site's hostname. Rename them to the sites they belong to while you still know which is which.
Which apps hand over their own database credentials
Cloudways gives every application its own MySQL database and its own user. Whether you ever have to look them up depends entirely on the format the app stores them in.
For anything else, the values live in Cloudways under Application Management → Access Details. Copy them into a database job once and it is done — a manually created job is identical to a detected one in every other respect.
WordPress
public_html/wp-config.phpDB_NAME, DB_USER, DB_PASSWORD and DB_HOST are pulled straight out of the define() calls. This is the common case on Cloudways, and it is the one that needs nothing from you.
Laravel and Craft CMS
public_html/.envTold apart by whether an artisan or a craft binary sits beside the file. Craft 4 and 5 use the CRAFT_DB_ prefix, Craft 3 does not; both are read.
Ghost
config.production.jsonThe database block is read only when its client is mysql. A Ghost install on SQLite is still detected and still gets a file job — the SQLite file is inside the directory being archived anyway.
What is not in a Cloudways backup
A file job archives a directory and a database job dumps a database. Neither of them knows the word Cloudways, and four things follow from that.
Anything outside the path the job archives
Detection proposes the application's document root, and that is what gets tarred. Your PHP version, Varnish and Redis settings, cron entries you defined in the Cloudways panel, and TLS certificates all sit outside it. Add extra file jobs for paths you care about, and expect to re-set the panel-level settings by hand on the far side of a rebuild.
A one-click restore
What you get back is a .tar.gz and a .sql.gz sitting in your own bucket. Restoring onto a fresh Cloudways application means creating the app in the panel first, extracting into its public_html, and piping the dump into its database using that new app's credentials — which will not be the old ones. The upside is that neither file needs us to open it.
Any involvement with Cloudways' own backups
VPS Snaps does not read, trigger, restore, or delete anything in Cloudways' backup system, and cannot. The two run beside each other and neither knows about the other. If you keep both, you keep both on purpose.
Apps whose config lives somewhere unusual
The scan is find and cat, three directory levels deep from each known root. It writes nothing and installs nothing — which also means an install that keeps its config outside those roots simply will not appear in the results. Add that job by hand; nothing about it is second-class.
The jobs underneath the button
Detection is a convenience layer. What it creates are ordinary jobs, and you can create them by hand any time.
File backups
The job type behind every app in the list: tar and gzip over your list of paths, minus your exclude patterns, streamed to your bucket.
Read moreDatabase backups
mysqldump for the MySQL databases Cloudways provisions per app, and pg_dump if you have Postgres elsewhere. Compressed on the server, checksummed in flight.
Read moreApplication detection
The full picture of what the scanner looks for, which platforms give up credentials, and where the scan comes back empty.
Read moreFAQs
Can’t find the answer you’re looking for? Reach out to our support team.
Does this work the same on Cloudways' DigitalOcean, AWS, GCP, Linode and Vultr servers?
Yes — nothing in the job knows or cares which cloud is underneath. It is an SSH session to an IP address, a tar or a mysqldump on the far end, and an upload to your bucket. What does depend on the underlying cloud is provider snapshots: those call the cloud's own API with a key you supply, so they only apply to instances living in a cloud account you control. If the machine sits in someone else's account, backing the applications up over SSH is the route that works — which is this page.
Can a job back up more than public_html?
Yes. Detection proposes the document root because that is the safe default, but a file backup job takes a list of paths and a list of exclude patterns, so you can add private_html, a shared uploads directory, or anything else on the box. Edit the job after it is created, or create one by hand and skip detection entirely.
Will it pick up my staging applications too?
If a staging application lives under a scanned root and carries a recognisable config file, it will show up in the results next to production. You can simply not create jobs for it, or create them and switch them off. Worth a moment's thought before you accept every row: two copies of the same site is two copies of the same storage bill.
Does anything get installed into WordPress?
No. There is no plugin, no mu-plugin, no admin login, and no PHP executed. Detection reads wp-config.php over SSH and pulls four values out of it with a regular expression. The backup itself is tar on your server and mysqldump against the database — WordPress is never running while either happens, and nothing is written into the site.
Where does the database password it found end up?
Encrypted with AES-256-GCM before it is written to our database, exactly like your SSH keys and your storage access keys. It is decrypted inside the worker when a run starts and handed to mysqldump on the far side of the SSH connection. A non-interactive SSH command does not land in that user's shell history.
What if my app is not one of the four the scanner understands?
You still get the file job — anything carrying a .env in a scanned root is detected and offered, it just arrives without a database job attached. Open Application Management → Access Details in Cloudways for that app's database name, user and password, and add a database job manually once. After that it runs on the same footing as every other job in the account.
Powerful features to give you peace of mind
Rest easy knowing your data and your reputation are safe.
- Bring your own storage
- Backups land in your own S3-compatible bucket — Backblaze B2, Wasabi, Cloudflare R2, or plain S3. You hold the keys and the data.
- Snapshots stay with your provider
- Provider snapshots are created through the provider's own API and never leave your account. We store the snapshot ID, not the image.
- Seven providers, one dashboard
- DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, Google Compute Engine and Microsoft Azure — scheduled and reviewed from the same place.
- Schedules that fit your traffic
- Hourly, daily, weekly, monthly, or a fixed interval in minutes — anchored to your timezone, so a 02:00 job stays at 02:00 across a DST change.
- Retention that prunes itself
- Set how many days to keep. Older snapshots and archives are cleaned up after each successful run, so storage bills stay flat.
- Step-by-step run logs
- Every run records what it did, in order, with warnings and errors kept in place — so a failure tells you which step broke.
- Complete run history
- Status, duration, byte size, and what triggered each run, kept per job. Proof the backup ran, long after the night it ran.
- Checksummed on upload
- Every archive is hashed as it streams to your bucket and the checksum is stored with the run, so you can verify what landed.
- Run on demand
- Trigger any job by hand before a migration or a risky deploy, without touching its schedule or its retention window.
- Alerts on five channels
- Email plus Slack, Microsoft Teams, Google Chat, and Discord — on success, on failure, and on a job that missed its schedule entirely.
- Encrypted credentials
- SSH keys, database passwords, and storage secrets are sealed with AES-256-GCM before they touch the database.
- Team access with roles
- Invite your team into a shared workspace as owner, admin, or member, so backups outlive whoever set them up.
“We host and manage websites for multiple clients, and manually checking backups was becoming a real headache. Being able to schedule both site files and database backups, set retention policies, and quickly review backup history gives us a much better process for protecting client sites.”
Your Cloudways apps, in a bucket you own.
Add the server, run detection once, and every application on it has its own file and database job by the end of the afternoon.
No credit card required. Cancel anytime.