Cloudways Security and SSL Guide

Cloudways gives every application a free Let’s Encrypt SSL certificate and ships with a server-level firewall, fail2ban, and Patchstack vulnerability scanning out of the box. Most users still leave one or two configuration gaps open: HTTPS redirect not enabled, mixed-content warnings on the homepage, or file permissions set too loose after a manual SFTP upload. This hub covers the full security baseline plus the add-on choices (Cloudflare Enterprise, Malcare, SafeUpdates) that make sense for higher-risk sites.

What This Guide Covers

For the broader provider context, see our Cloudways hosting guide. This page focuses on three jobs: getting SSL installed and renewing cleanly, hardening WordPress on top of the server-level protections Cloudways already provides, and resolving the most common security errors (permission denied, mixed content, infinite redirect loops, certificate chain warnings). All of the child guides linked below give the click-by-click steps; this page is the decision and overview layer.

Free Let’s Encrypt SSL on Cloudways

Every Cloudways application qualifies for a free Let’s Encrypt SSL certificate. It renews automatically every 90 days, supports unlimited domains and subdomains per application, and installs in under a minute from the Application Settings panel. The certificate is a standard Domain Validation (DV) cert, which is enough for blogs, marketing sites, and most WooCommerce stores. The full click-by-click setup with screenshots is in how to install SSL on Cloudways.

If you need a wildcard certificate (to cover all subdomains under one cert), the Let’s Encrypt option supports that too, but the DNS-01 challenge means you need to add a TXT record at your DNS provider during issuance. For sites that need Extended Validation (the green-bar visual indicator in older browsers) or Organisation Validation, you can install a paid third-party certificate by uploading the cert and private key through the same Application Settings panel.

HTTP to HTTPS Redirect

Installing the certificate does not automatically force visitors onto HTTPS. Without a redirect, half your traffic might still hit the insecure version, which loses SEO equity, breaks the padlock icon, and exposes form submissions. The fix takes one click in the Application Settings panel. The walkthrough is in how to redirect HTTP to HTTPS on Cloudways.

If you front the site with Cloudflare, set the Cloudflare SSL mode to Full (Strict), not Flexible. Flexible mode causes infinite redirect loops on Cloudways because the origin already has a real certificate. Full (Strict) is the correct setting for any site with a valid origin certificate.

Server-Level Security Cloudways Provides

Several layers are on by default and do not require any setup on your part:

• Server-level firewall via Imunify 360 blocks malicious IPs and common attack patterns before requests reach PHP.
• Fail2ban monitors SSH and SFTP login attempts. After three failed logins from the same IP, that IP is banned automatically.
• Patchstack scanning checks installed WordPress core, plugins, and themes against a CVE database and surfaces vulnerabilities in the dashboard.
• Automatic OS patches. Cloudways pushes Debian and stack updates without you needing to manage server packages.
• WAF rules for CMS-specific threats, brute-force login protection, and a web honeypot that traps known bots.

None of these need configuration. Cloudways enables them at the server layer for every application.

Cloudways Security vs Shared Hosting

The security model on Cloudways is fundamentally different from what you get on a traditional shared host like Bluehost or SiteGround. On a shared cPanel host, dozens or hundreds of websites share the same server kernel. A compromised site in the same shared pool can sometimes affect neighbouring accounts through local privilege escalation exploits, and while hosts add server-level tools like mod_security, they cannot fully isolate one account from another at the kernel level. You are trusting both your own practices and those of every other customer on the same machine.

On Cloudways, each application runs in its own containerised environment at the OS level. Fail2ban applies per server rather than across a shared pool. Root access means you can inspect log files, run security scans at the system level, and configure stack components directly. Patchstack and the WAF are per-application, not shared across unrelated sites.

The trade-off is real: shared hosting is simpler because the host manages security almost entirely for you. Cloudways gives you more control, but that control comes with more responsibility. If you want to set up hosting and never think about server-level security again, Cloudways is not the right fit. If you want the ability to inspect, harden, and monitor your own environment, it is a better choice than shared hosting for sites where security matters.

WordPress Hardening Tasks You Should Do

Server protections only stop a portion of attacks. The other portion targets the application layer (WordPress itself), and that is your responsibility. The minimum checklist for a Cloudways WordPress install:

• Use a unique admin username (not “admin”, not your domain name).
• Set a 16+ character password and store it in a password manager.
• Enable two-factor authentication, either through the Wordfence plugin or a dedicated 2FA plugin.
• Audit installed plugins quarterly. Remove anything you do not use. Each abandoned plugin is a future CVE.
• Disable file editing in the dashboard by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php.
• Limit login attempts at the WordPress level with a plugin like Limit Login Attempts Reloaded, even though Fail2ban catches SSH attempts.
• Change the database table prefix away from the default wp_ on new installs (post-install changes are harder but possible).

None of these are Cloudways-specific. They apply to any WordPress site, but they matter more on a server you actually own resources on, because a compromised application has access to those resources.

File and Folder Permissions

“Permission denied” errors on Cloudways usually trace back to one of three causes: a manual SFTP upload that did not preserve mode bits, a plugin that wrote files as the wrong user, or someone running chmod 777 as a quick fix and breaking the security model. The correct WordPress permissions are 644 for files and 755 for folders, with wp-config.php at 600. Cloudways provides a one-click reset that puts every file back to the right value.

The full walkthrough is in how to reset file and folder permissions on Cloudways. Use the reset whenever you see permission-denied errors during plugin updates, file uploads, or SSH operations.

DDoS, Bot, and Advanced Protection (Add-ons)

The built-in WAF handles standard attack volumes. Three paid add-ons step up the protection for sites that need it:

Cloudflare Enterprise ($4.99/month per application) provides layer 3, 4, and 7 DDoS mitigation, an enterprise WAF, and full-edge caching. This is the right choice if you have a high-traffic site that is occasionally targeted by botnets or scraper farms.

Malcare (varies) is an automated malware scanning and removal service. It runs continuous scans on your WordPress files and database, alerts you when something is flagged, and offers one-click cleanup. Worth the cost if your site has ever been hacked or you handle e-commerce data.

SafeUpdates ($4/month per application) handles WordPress core, plugin, and theme updates on a staging clone first, runs visual regression checks, and only promotes to production if nothing breaks. The right choice for agencies managing client sites where downtime from a bad update is costly.

Troubleshooting Common SSL and Security Errors

Five issues account for almost all SSL and security tickets:

• Mixed-content warnings (padlock with exclamation mark). The page loads over HTTPS but pulls images, scripts, or CSS over HTTP. Fix with a Better Search Replace pass on the database to swap http://yourdomain.com for https://yourdomain.com.
• Infinite redirect loop. Almost always a Cloudflare SSL mode mismatch. Set it to Full (Strict). If you do not use Cloudflare, check that you have not also added a redirect rule in .htaccess that conflicts with the Cloudways panel toggle.
• “Cloudways SSL not working” after a domain change. The certificate is bound to specific domains; if you change or add a domain, you need to re-issue the certificate from Application Settings.
• Certificate chain incomplete warning in some browsers. Re-install the cert. Let’s Encrypt sometimes serves an intermediate chain that older clients do not accept, and a fresh install bundles the current chain.
• SFTP “permission denied”. Reset file permissions via the dashboard (see above), then verify your SFTP user is the application user, not the master user, when accessing wp-content.

Security Monitoring and Incident Response

If you suspect a site has been compromised, the first stop is the Cloudways application logs (access log, error log, PHP error log). Unusual POST requests to xmlrpc.php, wp-login.php, or admin-ajax.php from a single IP are a strong signal of a brute-force or vulnerability scan. The Application Management panel surfaces all three log types. For wider context on what each log captures, the platform overview is in our Cloudways review.

Cloudways Account Security: Protecting Your Dashboard

Most security guides for Cloudways focus on the server and WordPress layers but skip securing the Cloudways dashboard itself. A compromised Cloudways account gives an attacker full control over every server and application in it, so dashboard access is worth hardening explicitly.

Enable Two-Factor Authentication

Cloudways supports two-factor authentication (2FA) for your account login. Enable it under Account > Profile > Two-Factor Authentication. Use an authenticator app (Google Authenticator, Authy) rather than SMS where possible. Once 2FA is active, every login from a new device requires the six-digit code from your authenticator app in addition to your password.

Restrict Team Member Permissions

If you use Cloudways team access, apply the principle of least privilege. Under Account > Team Members, you can assign roles that limit what each team member can see and do. A developer working on one application does not need access to billing, server creation, or other applications. Review team member permissions whenever someone leaves your organisation.

Manage SSH Keys, Not Passwords

When you enable SSH access on a Cloudways application, the default is password-based authentication. Switch to SSH key-based authentication instead. Add your public key under Server > Master Credentials > Add SSH Key, then disable password authentication in the server’s SSH configuration. This eliminates brute-force attacks against the SSH port entirely.

Rotate API Keys Periodically

If you use the Cloudways API for automation or integrations, review active API keys periodically under Account > API Access. Revoke keys that are no longer in use. Do not share API keys across multiple integrations; generate a separate key per use so you can revoke a single key without breaking all integrations at once.

What to Do If Your Cloudways WordPress Site Gets Hacked

Even with Cloudways protections in place, WordPress sites can get compromised through outdated plugins, weak passwords, or vulnerabilities in themes. The recovery process on Cloudways is faster than on shared hosting because you have full server access and offsite backups. Here is the step-by-step response:

1. Take the site offline immediately. In the Cloudways dashboard, go to Application Settings and disable the application or put it into maintenance mode using a plugin. Keeping a compromised site live allows the attacker to continue operating and may get the domain blacklisted by Google.
2. Restore from a clean backup. Go to Application Management > Backups and restore from a snapshot that predates the compromise. Cloudways keeps daily backups for up to 4 weeks depending on your retention setting. If you are not sure when the breach occurred, restore from at least two weeks back.
3. Change all credentials. After restoring, change the WordPress admin password, the Cloudways account password, your SFTP/SSH credentials, and any database passwords exposed in wp-config.php. Rotate these even if the backup predates the breach, since the attacker may have extracted credentials and the restored site would be vulnerable again.
4. Scan with Malcare or Wordfence. Run a full malware scan on the restored site before bringing it back online. Malcare can scan and clean without needing FTP access. Wordfence’s free scanner checks core file integrity against the WordPress.org repository checksums.
5. Identify the entry point. Look at the Cloudways access logs for the period before the incident. Attackers typically leave POST request spikes to wp-login.php (brute force), xmlrpc.php (XML-RPC amplification), or a specific plugin endpoint. Check the Patchstack dashboard for any flagged vulnerabilities that were unpatched at the time.
6. Patch before going live. Update WordPress core, all plugins, and all themes. Remove any plugins or themes that have open CVEs and no available patch. Confirm file permissions are correct (644/755) with the Cloudways one-click reset.
7. Request a Google review. If Google flagged the site as dangerous in Search Console, submit a reconsideration request after cleanup. This typically takes 1 to 3 days to clear the warning.

The most common attack vectors on Cloudways WordPress sites are nulled plugins, outdated plugins with known vulnerabilities, and reused passwords across multiple accounts. Cloudways’s server-level tools reduce the blast radius of an attack but cannot substitute for keeping the WordPress application itself current.

Cloudways Security Quick-Reference Checklist

Use this checklist when setting up a new Cloudways application or auditing an existing one:

• SSL installed and HTTPS redirect enabled -- check Application Settings > SSL. Both the certificate toggle and the Force HTTPS toggle should be active.
• Cloudflare SSL mode set to Full (Strict) -- only applies if your site is proxied through Cloudflare. Flexible mode causes redirect loops.
• WordPress admin username is not “admin” -- create a new admin account with a unique username and delete the default one.
• Strong password (16+ characters) on all admin accounts -- use a password manager to generate and store it.
• Two-factor authentication enabled via plugin -- Wordfence or a dedicated 2FA plugin covers this at the application level.
• Fail2ban active -- confirm via Server Management > Security in the Cloudways panel.
• Patchstack alerts enabled -- check the Cloudways dashboard for any flagged plugin or theme vulnerabilities.
• File permissions correct (644 for files, 755 for folders) -- reset via Application Settings if you have run any manual SFTP uploads or seen permission errors.
• Plugin audit done in the last 90 days -- deactivate and delete anything not actively in use.
• Automatic backups enabled -- configure under Application Management > Backups. Daily backups with a 7-day retention window is a reasonable baseline.

For ongoing protection, the most cost-effective combination on Cloudways is: enable HTTPS redirect, run Patchstack alerts, install a 2FA plugin, and audit installed plugins quarterly. If you handle payments or customer data, add Cloudflare Enterprise on top. To start the free trial and test these features yourself, sign up for Cloudways directly. For a complementary look at performance settings, our guide on how to make Cloudways faster for WordPress covers Varnish, Redis, and CDN configuration.