Cloudways root access: what you can and can't change

Cloudways does not give root or sudo access on any server, on any plan, at any price. You get SSH as a "master" user who owns all the applications on the server, a dashboard for PHP and database settings, and a menu of packages you can install. For WordPress and most PHP applications that covers everything you need. If you need to install system software yourself, Cloudways is the wrong product.

This guide explains why Cloudways holds that line, what you can still do without root, and a list of common needs with the Cloudways way of doing each one, or the honest answer that there is no way.

Why Cloudways will not give root access

Cloudways' explanation is that it is a platform rather than a collection of separate servers. Every customer server runs tools that Cloudways uses to apply updates, take backups, monitor health and push configuration changes across its whole fleet. Root access would let a user stop or break those tools, and then Cloudways could no longer manage that server the way it manages the rest.

The same reasoning explains a less obvious rule: you cannot connect your own AWS, Google Cloud or DigitalOcean account. Cloudways creates every server in its own provider accounts, because in your account you could bypass the restrictions from the cloud console. So "bring your own cloud credits" is not an option either.

What the master SSH user can do

Each Cloudways server has master credentials, shown on the server's page, with SSH enabled by default. The master user can read and write every application's files, and run the tools developers actually use day to day:

• Composer, Git and WP-CLI, so you can install PHP dependencies, pull code and run WordPress commands such as search-and-replace or plugin updates.
• Node.js tooling at user level, enough to run npm builds for a theme's front-end assets.
• MySQL and Redis command-line access for your own databases, plus a browser-based database manager.
• Log files for each application, including web server and PHP error logs.

Each application also has its own credentials that land you in that application's folder only, which is how you give a freelancer access to one site. Access is over port 22, and you can restrict it to known IP addresses from the server's security settings. Our SSH and SFTP guide walks through connecting.

What the dashboard replaces

Most of what people use root for on a web server is configuration, and Cloudways moves that into its dashboard:

• PHP settings. Memory limit, maximum execution time, upload size, input variables, error display and timezone, under Settings & Packages. Per-application PHP-FPM settings can be adjusted too.
• Versions. PHP from 7.4 up to 8.4, MySQL 8.4 or MariaDB 10.11. Database versions cannot be downgraded once raised.
• Packages. Redis, Elasticsearch, OpenSearch, Supervisor, RabbitMQ and others install from a list. Additional PHP extensions or Apache modules can be requested through support.
• Services. Restart NGINX, Apache, PHP-FPM, MySQL, Redis, Varnish or Memcached from Manage Services when something hangs.
• Scheduled and background jobs. A cron manager per application, and Supervisor jobs for Laravel queue workers.
• Redirects and headers. On the Lightning Stack, Web Rules replace .htaccess with up to 25 redirect rules and 10 header rules per application.

Common needs, and whether Cloudways can meet them

What to ask support for

Several things that look like they need root can be done by Cloudways' support team on request, on the standard free tier: enabling a PHP extension or Apache module that is not on by default, checking whether a package your application needs can be installed, adjusting a server setting that is not in the dashboard, or investigating why a service keeps stopping. Support decides case by case, because anything they enable has to fit the managed platform. Ask before you assume something is impossible; ask early, during the trial, if your project depends on it. Our support review covers what each tier handles.

The upside of not having root

It is easy to treat the restriction as pure loss, but it protects you as well. With no sudo, nobody on your team, and no compromised plugin running as your user, can remove the monitoring agent, disable updates or change system packages in a way that breaks the next security patch. Cloudways can only keep the operating system patched and the stack consistent because nobody else is changing it underneath.

For a business that hires freelancers or hands sites to clients, that matters. The worst a freelancer can do is break the application they were given access to, and backups and staging cover that.

When to host somewhere else

If something on the "No" list above is central to your project, do not try to work around it. The common patterns are:

• Mostly PHP, with one non-PHP service. Keep the sites on Cloudways and run the extra service on a small unmanaged server. A $6 DigitalOcean Droplet or a $4 Kamatera server can host a Node.js API or a queue worker next to your Cloudways sites.
• You need a custom stack throughout. Go fully unmanaged and use a server panel if you want help with WordPress. Our Cloudways vs RunCloud comparison covers the panel route, where you keep root.
• You need root for compliance or auditing tools. An unmanaged VPS or a dedicated server is the only fit, and our Cloudways vs DigitalOcean comparison sets out what you take on.

Before you commit, it is worth checking your actual needs against the server rather than a feature list. The 3-day trial gives you master SSH access on a real server, which is enough to try your deployment scripts and see which steps fail without sudo.