How to Host Joomla, Drupal, Laravel and Custom PHP Apps on One cPanel Account Safely

A cPanel account can hold a lot more than one WordPress site: a Joomla portal, a Drupal site, a Laravel application and a few custom PHP scripts often live side by side, usually because each was added when a client needed it. That works fine until one of them is hacked. The important fact to design around is this: on cPanel the security boundary is the account, not the individual app. Everything inside one account runs as the same Unix user, so a weakness in one script can read and change the files of all the others. This guide explains where the boundary sits, how to arrange several apps in one account, which per-app settings matter for Joomla, Drupal, Laravel and plain PHP, how to stop uploads from running code, and when it is time to split apps into separate accounts.

The real boundary is the cPanel account#

On a CloudLinux server, CageFS gives every account its own virtualized file system, so customers cannot see each other’s files or system files. That protects one account from another. It does nothing between two apps inside the same account, because both run as the same user and both see the same home directory. Resource limits work at the same level: CloudLinux sets limits on CPU, memory, processes and entry processes per account, so a runaway script in one app can slow down every other app in the account.

The consequence is simple. If an outdated Joomla extension is exploited, the attacker has the permissions of the whole account. They can read the Laravel .env file with its database password, edit your Drupal settings, plant a backdoor in a WordPress theme and read any backup archive in the home directory. Treat everything in one account as sharing one fate.

One account or several?#

On a reseller or WHM plan, creating another account costs very little, and it is the strongest form of isolation cPanel offers.

A safe layout for several apps in one account#

• One folder and one domain or subdomain per app. Do not install one app inside another’s folder. A Joomla site under public_html/shop inherits every weakness of the site above it.
• Keep code and secrets outside the web root where the app allows it. Laravel is the model: only its public folder is served. Our guide to deploying Laravel on cPanel shows the setup.
• One database and one database user per app. In cPanel, MySQL Databases lets you create a separate user for each database. If one app’s credentials leak, the others stay protected.
• Unique passwords and keys everywhere. Never reuse a database password, an admin password or an application key between apps.
• No leftovers in the web root. Joomla’s documentation says every unused file is a potential security hole. Remove old installers, test scripts, phpinfo files, and zip, sql or backup archives from folders the web serves.

Per-app hardening checklist#

One cPanel-specific detail matters for Drupal and Joomla. PHP normally runs as the account owner, so a file at 644 is still writable by PHP, and Drupal will still warn about it. Removing write permission for everyone, including the owner, is what counts:

cd ~/public_html/drupal-site
chmod 444 sites/default/settings.php
chmod 555 sites/default

Run these from the Drupal root of your own site, and replace the folder name. When you need to edit the file or run an update, temporarily restore write access with chmod 644 or chmod 755, make the change, then lock it again.

Stop uploads from running PHP#

Many compromises start with an uploaded file that is really a PHP script. Every folder that accepts uploads, such as wp-content/uploads, Joomla’s images folder or Drupal’s sites/default/files, should refuse to execute PHP. On Apache, add an .htaccess file inside that folder:

<FilesMatch ".php$">
    Require all denied
</FilesMatch>

Then test it. Put a harmless file named test.php in that folder and open its URL: you should get a 403 Forbidden error, not a blank page. Delete the test file afterward. If you get a blank page, the rule is not being applied, and you should ask your host whether .htaccess overrides are allowed for your account.

Audit the account regularly#

These read-only commands, run in SSH or cPanel’s Terminal, find the most common problems:

find ~/public_html -perm -0002 ! -type l
find ~/public_html -path "*uploads*" -name "*.php"
find ~/public_html -name "*.zip" -o -name "*.sql" -o -name "*.bak"
ls -la ~/public_html

The first command lists anything world-writable, which should be empty. The second shows PHP files inside upload folders, where there should be none apart from harmless index placeholders. The third finds archives and backups that someone left in the web root, and the fourth lets you spot folders and files you do not recognise.

Optional extra layers#

• open_basedir. This PHP setting limits which directories a script may open. Set per domain in MultiPHP INI Editor, or in the options screen of Select PHP Version, it can confine an app to its own folder. It is not a complete defense, and it can break tools that need to read outside the folder, so test carefully after changing it. See our guide to choosing the PHP version and handler in cPanel for where these settings live.
• PHP-FPM pools. cPanel can run a separate PHP-FPM pool for each domain. This separates processes and settings, but by default the pool still runs as the account user, so it is not a replacement for separate accounts.
• A malware scanner. If your host provides one, such as ImunifyAV, schedule regular scans of the whole account.

If one app is compromised#

Assume the whole account is affected until you have shown otherwise. Put the affected site into maintenance or take it offline, then work through the account in order:

1. Change the cPanel, database and FTP or SSH passwords, and rotate every application key and API token stored in .env or config files.
2. Check the other apps for modified files, unknown PHP files and new administrator users.
3. Review cron jobs and any extra FTP or email accounts for entries you did not create.
4. Restore the damaged app from a clean backup, update it to the latest version and remove the vulnerable extension or plugin.
5. Scan the account again before putting the site back online.

When to move apps out#

If you host work for clients, move each client to their own account. If an app needs custom services, queues or long-running processes, a VPS or dedicated server lets you separate it properly. For everything else, a well-kept cPanel hosting plan with updated apps, tight permissions and per-app databases is a sound base, and an SSL certificate on every domain keeps logins and sessions encrypted.

Related guides: hosting multiple websites on one VPS with Nginx and setting up free SSL on Nginx with Certbot. To lock down the account these apps share, read how to keep your cPanel account and sites secure.

Frequently asked questions#

Is it safe to run multiple websites on one cPanel account?#

It can be, if they belong to one owner and every app is kept updated. The risk is that a flaw in any one of them exposes the others. For different clients, use separate accounts.

Does CageFS protect one site in my account from another?#

No. CageFS isolates accounts from each other. Inside one account, all apps share the same user and the same home directory.

What permissions should my files have?#

Use 755 for directories and 644 for files, and make configuration files read-only once the site is set up, as with Joomla’s configuration.php and Drupal’s settings.php. Do not use 777.

Should every app have its own database user?#

Yes. A separate database and user per app means leaked credentials only expose that app’s data, and it makes cleanup after an incident much simpler.

The short version: remember that the account is the boundary, give each app its own folder, database and secrets, lock configuration files, stop uploads from executing and split risky or client apps into their own accounts.